DSpark corrupts output on the aprojq4-dense-attention branch (GB10/CUDA): intra-word syllable doubling, confined to the full-accept path

Reporting a DSpark output-corruption issue observed on GiorgioOppo's `aprojq4-dense-attention` branch (`f0541235`, the branch behind #952). **This is a branch issue, not a property of the AProjQ4 requant** — the requant measurements are in #952 and are clean.

**Setup**: NVIDIA GB10 (sm_121), DGX Spark, 121 GiB unified memory, CUDA backend, single GPU, no TP, no SSD streaming. CLI `./ds4`, `--temp 0 --nothink`, `-n 300`, `-c 131072`, official `DeepSeek-V4-Flash-DSpark-support-0731.gguf`.

## Symptom

With DSpark enabled, **syllables get duplicated inside words**: `deklarklaracji`, `żadenaden`, `Brakujeuje`, `uznznąymi`. The surrounding text stays coherent — this is not a loop and not degeneration. Most visible in morphologically rich languages (examples above are Polish), but it also occurs in English.

## Scope

**Zero** such corruptions in every upstream build I tested, including `c0a6119`. Present on this branch with both the AProjQ4 model and the base IQ2_XXS model.

## The part that may localize it

Two campaigns, eight runs, using the `full=`/`partial=` counters from `DS4_DSPARK_STATS=1`. Model AProjQ4, Polish prose. "Doublings" counted by regex `\b\w*?(\w{3,})\1\w*\b` on the generated text, digit-only matches excluded.

| prompt | setting | drafter | `full`/`partial` | syllable doublings |
|---|---|---|---:|---:|
| 8k | default threshold (0.7) | official | 29 / 3 | **2** |
| 8k | `--dspark-confidence 0.0` | official | **2 / 34** | **0** |
| 100k | default threshold | official | 37 / 10 | **8** |
| 100k | `--dspark-confidence 0.0` | official | **1 / 49** | **0** |
| 8k | default threshold | Q4_K experts | 27 / 6 | **3** |
| 8k | `--dspark-confidence 0.0` | Q4_K experts | **6 / 70** | **0** |
| 100k | default threshold | Q4_K experts | **59 / 10** | **6** |
| 100k | `--dspark-confidence 0.0` | Q4_K experts | **1 / 33** | **0** |

In all four runs where full accepts numbered 1–6, doublings are **exactly zero**; in all four where they numbered 27–59, doublings are present. That suggests the corruption arises in the **full-block commit path**, rather than in proposal, in verification as such, or in replay — replay handles the partial accepts, and those runs are clean.

**What this does not show**, stated explicitly: there is no dose–response. 59 full accepts produced 6 doublings while 37 produced 8. That fits a state-dependent fault better than a systematic arithmetic one. I predicted proportionality before running the second campaign and that prediction failed, so please treat the mechanism as open — the reliable part is the separation, not a diagnosis.

## Reproduction

```sh
DS4_DSPARK_STATS=1 ./ds4 --temp 0 --nothink -n 300 -c 131072 \
-m --dspark --mtp-model DeepSeek-V4-Flash-DSpark-support-0731.gguf \
--prompt-file <~90k tokens of ds4 source + an instruction>
```

Then grep the output for repeated 3+ character sequences inside words, and compare against the same run without `--dspark`.

## Ruled out by measurement

- the AProjQ4 requant itself (corruption also occurs with the base model on this branch)
- WaveCut's DSpark module vs the official one (identical behaviour)
- the last eight commits on this branch
- the absence of each of three upstream fixes, tested individually
- Polish tokenization (corruption also occurs in English)

## Workaround for anyone on this branch

`--dspark-confidence 0.0` produces clean output (zero doublings, 100% unique shingles), but the speedup drops to about +2% at a 100k prompt.