qwen35: apply the Hadamard inverse to the MTP token-embedding lookup

[renovys]

Based on #188 (PQ2_0 support), which is not yet merged, so the diff below #188 shows its commits too; the net new change here is the final commit. Happy to rebase once #188 lands.

qwen35: apply the Hadamard inverse to the MTP token-embedding lookup

Problem — --spec-type draft-mtp cannot start on Hadamard-latent models (patch=required)

For qwen35 models whose token_embd.weight is a Hadamard-latent table
(prism.hadamard.inverse_weight_names, e.g. Ternary-Bonsai-2-27B
PQ2_0-MTP), the MTP draft graph reuses model.tok_embd when the model has
no nextn.embed_tokens (qwen35.nextn_predict_layers = 1).

graph_mtp consumed the raw ggml_get_rows(tok_embd_w) output — the latent
rows — without restoring the primal basis. llama_verify_hadamard_graph
(llama-context.cpp, hadamard_verified per context) detects a latent table
being read without the inverse transform and throws:

std::runtime_error("Hadamard-latent table ... read without the inverse transform")

So on the unpatched tree the first MTP draft-graph build throws, draft
context creation fails, and --spec-type draft-mtp is unusable — not a
slowdown, a startup-correctness failure. Verdict: patch=required.

Change

In src/models/qwen35.cpp graph_mtp, right after the embedding lookup,
apply the same inverse that build_inp_embd() applies for the main graph:

• if hadamard_inverses contains the embedding tensor, run
  llama_mul_mat_hadamard(ctx0, tok_embd, rot) and multiply signs when present.

This mirrors the existing main-graph path exactly; when the table is not
latent-registered the behavior is unchanged.

Evidence (BC-250, RADV GFX1013, Ternary-Bonsai-2-27B-PQ2_0-MTP-Q8_0.gguf)

arm	binary	spec	result
A	unpatched	draft-mtp	fails by construction (throw path proven above; live attempt aborted on memory-pressure guard, not needed — the throw is deterministic)
B	patched	draft-mtp	31.10 t/s, draft_n 134, accepted 82 (61.2%)
C	patched	none	22.97 t/s

• B vs C output: same prompt, temp 0, n=128 — content sha256 62156b08640d3047
  byte-identical on 3/3 runs. The patch produces correct output, not just a
  faster wrong one.
• Production run (2026-09-21, live server, ctx 65,536, 2 slots): 3 consecutive
  measures 30.13/30.29/30.28 t/s, draft_n 134 / accepted 82 every run.

Correctness

• test-backend-ops -b Vulkan0 -o MUL_MAT,MUL_MAT_ID,GET_ROWS: 2310/2310 pass,
  0 FAIL (includes Bonsai-2 real shapes).
• The Hadamard verifier itself remains the regression tripwire: if the inverse
  were dropped or applied twice, first MTP graph build throws.

Notes for review

• hadamard_inverses map lookup is per-tensor; non-latent models and
  nextn.embed_tokens-carrying models take the same path as before.
• Draft context uses its own hadamard_verified flag — this fix is what lets
  that verification pass instead of throwing.

[renovys]

Validated the equivalent fix on a live BC-250 (gfx1013) service (via 62e04aad1 in our tree): draft-mtp runs at ~30 t/s with ~61% accept rate and no throw.

[renovys]

Closing as a duplicate to keep the queue clean: #205 has landed in prism (422590f, merge of zhaoyilun's mtp-hadamard-embedding) carrying the same inverse-Hadamard on the token embeddings the qwen35 MTP draft graph reads. We verified the equivalent on our BC-250 service, so folding this copy into that decision. Thanks all for the reviews and cross-references.