feat(MODEL-MM-QWEN4-EXP): W2 — the hashed n-gram index and the PLE dilated conv, the two components with no vLLM op

[localai-bot]

The two components of Qwen4ExpForConditionalGeneration that have no vLLM op at
all: the hashed n-gram index construction, and the PLE layer with its dilated
depthwise causal conv. git grep -in dilat over vLLM's layers/mamba/ returns zero,
and layers/conv.py defines only Conv2dLayer and Conv3dLayer, so transformers
5.16.0 — this row's accepted lane pin — is the sole source for both. Host
reference; the device arm is owed.

This is integer-exact or it is silently wrong, and there is no downstream gate that
would localise an error here. Three divergence sites are named at the site and each is
mutation-covered: _splitmix64 must be uint64_t throughout, because its shifts are
logical on a non-negative Python int and become arithmetic on a signed one, with the
top bit set about half the time; its % half_bound must be an unsigned modulo,
because the dividend routinely exceeds 2^63; and the 128 shards of the released table
must be reassembled in numeric order, since a lexicographic key sort gives
shard_0, shard_1, shard_10, ... and silently permutes a 95 GiB table.

The forward itself needs no bignum: layer_multipliers[i] is a 0-dim int64 tensor, so
the product is int64 arithmetic, bounded below 2^63 because
multiplier_max * vocab_size <= 2^63 - 1. That bound holds only while every token
id is in range, which is why the port refuses an out-of-range id where upstream does
not need to.

The goldens are quadruply confirmed. config.seed is absent from the released
config, so the dataclass default 1234 applies, giving
layer_multipliers = [23703573157769, 20109073645365, 8052911324071]. That value was
reached four independent ways: reconstructing the splitmix64 chain; a range read of the
buffer out of the released safetensors; the qwen4exp.ple.layer_multipliers key in
unsloth/Qwen3.8-Flash-Next-GGUF; and a brute force showing vocab_size = 248320 is
the unique preimage below 2e6 at that seed.

The first review FAILED this change, and the finding was a real silent divergence.
eos_token_id bypassed the range refusal that the whole safety argument rests on: it
defaults to -1, Reset seeds the n-gram history with it unvalidated, and it
reaches the uint64_t multiply on the FIRST token of every sequence, since
ShiftRightIgnoreEos emits EOS at every segment start. Measured against a running
oracle on the same 12 tokens: at eos = -1 upstream gives row-0 ids [2,35,67,96] and
we gave [8,30,67,96]; at eos = 1000000, [9,38,65,108] against [9,38,81,83]. No
exception, no shape change, different rows of a 320M-row table. A negative id makes the
product negative in torch, where torch.remainder normalises it, while our
static_cast<uint64_t> reinterprets the same bits as ~2^64.

The repair refuses by name at both entry points. It is a range check and not a blanket
refusal wearing one: three mutations exist purely to prove that — refuse-everything,
and each boundary shifted by one — and all three die on the CHECK_NOTHROW arm at
eos in {0, vocab_size-1}. The re-review went further and confirmed those valid
boundary values produce ids byte-identical to upstream, which is stronger than the
test asserts.

Three more gate defects the review found, all closed. The conv_mask path was entirely
ungated — deleting the whole masking block, or masking only one of the two tensors
upstream masks, both passed — and the new golden's mask is adversarial: its zeros sit
at interior positions 3 and 4, which the dilation-3 conv propagates to t = 6, 9 and 12.
The coverage proof is the strongest form available: with the new case present both
mutations are red, and with that one case excluded both go green again. IsPrime's
even-number arm had no test. And kNgramExpectedIds was produced by a transcription
of upstream's forward rather than by executing it — a transcription cannot gate the
function it transcribes, and the generator and the port transcribed the same upstream
lines, so a shared misreading would have passed. The generator now recovers the ids
from upstream's own executed forward through an invertible embedding, and the
regenerated file differs from the committed one by a single anchor comment: the values
were right, only the method was wrong.

Also corrected: a wrong anchor on the most load-bearing constant in the PLE half
(short_conv_state_len cited the nn.Conv1d( call, not its definition), and two false
measurement claims in a test comment — the forward's 2.38419e-07 is two ULP at
its argmax magnitude, not one, and its bound sits ~42x above the observation, not ~4x.

## Owed records the gap this wave's own gate cannot close: the whole instrument runs
at hidden_size = 8, and only the multipliers, primes and offsets are pinned at the
released config — those being integers. A first real-width numeric comparison is owed,
and it must derive a relative bound, because the sibling W3 wave measured that an
exact-double evaluation of the oracle's own algorithm already exceeds a 1e-5 absolute
bound at model width, torch running the reduction in fp32.

This slice lands unreached. qwen4_exp has no registry entry, no loader and no
ModelRegistry::Forward arm until W5 assembles the model; the commit body, the spec
## Owed and the index row each name that, the owning row and #1978.

Tracked by #1987, under #1978.

Gates: test_qwen4_exp_ple 9 cases / 395 assertions (up from 8 / 307);
agent-preflight.sh rc=0 with zero FAIL and zero SKIP — the origin/main merge was
needed because check-commit-trailers and check-commit-style had been SKIPping, and
therefore reporting nothing, while the branch was behind. A fresh review returned FAIL,
a different implementer repaired it, and a fresh scoped re-review returned PASS with
zero findings, each repair proved by re-running the mutation that used to survive.

FOLLOWING_AGENTS_PROTOCOL

Following-Agents-Protocol: true
AI-Assisted: true
Assisted-by: Claude:claude-opus-5 [Claude Code]