control-vector: add projective apply mode (h -= alpha*(h.d)d)

[msuiche]

Adds a projective apply mode to the existing control vector path, beside the
additive one it has always had.

Why

build_cvec() does h += v — it steers towards a direction. Refusal-ablation
work measures a different operation on the same container:

add       h <- h + v                   steer towards a direction
project   h <- h - alpha * (h . d) d   delete the component along one

These are not a scale factor apart, and that gap is the problem worth solving. A
projective direction loaded by the additive path raises no error and produces
wrong output: it pushes every token along the refusal axis instead of removing
that component. Tensor names, dtype and shapes are all valid, so nothing
downstream notices. Measured on stories260K with identical direction data, the
two differ by 5.13 max logit.

So the operation travels with the file as gguf key dspark.mode, and an
unrecognised value is fatal — there is nothing safe to fall back to. Absent key
means add, which is what every control vector written before this key existed is.

Motivating result: on a 304B-class MoE, a 478 KB projective control vector
reaches 0% refusal on four held-out offensive-security suites, matching a
re-uploaded abliterated checkpoint of the same model. Runtime-toggleable via
alpha, no weights redistributed.

What changed

file	change
include/llama.h	llama_cvec_apply_mode enum; llama_set_adapter_cvec_ex()
src/llama-adapter.{h,cpp}	projective branch in apply_to(); mode/alpha state; unit-norm warning
src/llama-context.{h,cpp}	plumb mode/alpha; old entry point wraps the new one
common/common.{h,cpp}	read dspark.mode / alpha_default / hook_point; refuse mixing
common/arg.cpp	track whether --control-vector-scaled was actually passed
tests/	four test binaries + fixture generator

llama_set_adapter_cvec() keeps its exact signature and delegates with
(ADD, 1.0f), so every existing caller and every pre-existing additive vector is
unaffected. That is asserted, not assumed.

The apply

ggml_tensor * coef = ggml_mul_mat(ctx, layer_dir, cur);              // [1, n_tokens]
ggml_tensor * proj = ggml_mul(ctx, ggml_repeat(ctx, layer_dir, cur), coef);
cur = ggml_sub(ctx, cur, ggml_scale(ctx, proj, alpha));

mul_mat contracts over the embedding axis for one coefficient per token; mul
against a [1, n_tokens] operand broadcasts it back, giving the rank-1 outer
product. ggml_out_prod would do this in one op, but Metal does not implement
GGML_OP_OUT_PROD (only CPU and CUDA do, ggml-cuda.cu:4969), so it would split
the graph and fall back to CPU on Apple silicon. These five ops run natively
everywhere.

Things the loader refuses rather than guesses at

• unknown dspark.mode
• dspark.hook_point naming a hook we do not apply at. The same direction applied
  after attn.wo_b instead of the post-layer residual measured 9x weaker, so
  this is a correctness field, not documentation.
• combining a project-mode file with any other vector. The existing loader sums
  across --control-vector arguments, which is meaningful for additive vectors
  only — two projections do not compose into a projection along the sum of their
  directions, and the sum of two unit vectors is not a unit vector.
• two direction tensors resolving to the same layer.

alpha is never folded into the data: projection is quadratic in the direction's
norm, so scaling d by s scales the removal by s^2.
--control-vector-scaled's strength becomes alpha for project-mode files. That
needed strength_set on the load info, because keying on strength != 1.0 cannot
tell an explicit -scaled f:1.0 from the 1.0 that --control-vector fills in,
and silently replacing a requested 1.0 with a file's 4.0 is a 4x difference in
ablation strength.

Tests

test-cvec-project — the op composition against a hand-computed projection.
Shape checks are not enough: a transposed operand or a broadcast along the wrong
axis still yields a correctly shaped tensor and plausible output. Asserts
(h'.d)=0 at alpha=1, elementwise equality at alpha=4, bit-exact identity at
alpha=0, orthogonal tokens untouched, idempotence at alpha=1. Runs in ctest, no
model needed.

test-cvec-model — logits on a real model. 27 assertions including:

assertion	result
alpha=0 is bit-identical to no vector at all	pass
alpha=1 changes logits	pass, max delta 4.20
alpha=4 moves further than alpha=1	pass, max delta 16.44
clearing the vector restores baseline exactly	pass
same data added vs projected	pass, max delta 5.13
every refusal path above	pass
two additive vectors still combine	pass

That last one matters: it fails if the new mixing check is too broad. And the
alpha=0 bit-identity check exists because a separate port of this shipped a bug
where the alpha=0 control traced a graph with the op removed and cached it, making
the entire ablation read as a no-op.

test-cvec-layer-map — pins direction.N to a graph layer by measurement.
The 1-based naming invites two readings: common_control_vector_load_one() stores
direction.N at offset (N-1)*n_embd, which reads like "N-1 is the layer", but
apply() then fills tensors[il] from (il-1)*n_embd, so the two -1s cancel and
direction.N lands at layer N. This test puts one direction in one slot and
sweeps single-layer ranges to see which layer responds.

It is here because reading the load function alone gave the wrong answer and
produced a wrong exporter elsewhere. A one-layer shift does not fail, it
degrades — adjacent layers' refusal directions have cosine similarity 0.83-0.91,
so a shifted stack still ablates, still answers coherently, and still passes a
smoke test.

test-cvec-inspect — prints mode, alpha, populated slots, resolved layer ids and
per-direction norms for any control vector, without loading the model it belongs
to. This is what surfaced the off-by-one above, by reporting layers 11-39 for a
file derived from layers 10-38.

Existing tests: 8/8 pass (test-arg-parser, test-sampling, test-chat*,
test-json-schema-to-grammar).

Note on cvector-generator

Not touched, but worth recording: it names the difference measured at layer il
as direction.{il+1} (mean.hpp:18, pca.hpp:305), so the generator and the
applier sit one layer apart. Whether that is deliberate or an old off-by-one, the
applier is what decides where a distributed file takes effect, so this PR matches
the applier and changes neither.

Scope

Vectors are checkpoint-specific; no cross-model transfer is claimed. rank > 1 is
expressible in the format but not implemented here, and measured no better than
rank-1 in the work this comes from.