fix(ci): restore the larql-vindex coverage gate

[chrishayuk]

The larql-vindex coverage gate has been red on main since #363. A permanently
red gate is worse than no gate: the next genuine coverage regression becomes
indistinguishable from the standing failure.

Seven entries, added for two different reasons that must not be conflated.

Debt — tracked in #367

Five gguf/* files landed with ~2,100 lines carrying four inline tests between
them (emit/, preflight/ and walk/ have none):

file	lines	tests	coverage
gguf/export.rs	419	1	50.8 %
gguf/emit/mod.rs	517	0	83.0 %
gguf/vocab.rs	400	3	83.4 %
gguf/walk/mod.rs	434	0	88.5 %
gguf/preflight/mod.rs	346	0	88.8 %

Baselined at today's levels — a ratchet, not an exemption. The gate is green
now and any drop below today still fails, so regression detection is restored
while the debt stays visible and owned. Raise them as tests land; do not lower
them.

Structural — do not chase with more tests

represent/kda_candidate_real.rs (4.4 %) is a #[cfg(test)] driver gated on a
real 48 B container the ubuntu job does not have; kda_candidate.rs (75.2 %)
carries gpu-gated paths the non-gpu coverage run cannot reach. Same class as the
integer.rs / stationary.rs / physical.rs entries the policy note already
documents, and the note now says so explicitly.

Verification

CI's own scripts/check_coverage_policy.py, against a measured report:

Coverage policy passed: total 93.42% lines, 365 files checked,
304 files at 90.0% default, 61 debt baselines.

Known unrelated reds

cargo-audit and cargo-deny · advisories (RUSTSEC-2026-0269) are red on main
independently of this change. The bench gate is separately unreliable — it
flagged a +31 % "regression" in larql-compute on a branch that did not touch
that crate; that is shared-runner variance against a main baseline and is the
next instrument fix, not addressed here.