…3-MOE-PARITY-001 DISCHARGED

Closes #1584.

## Discharge summary

Live test result on lambda-vector RTX 4090 (2026-05-09):

  cargo test --release -p aprender-serve --test qwen3_moe_parity -- \
    --include-ignored f_qw3_moe_parity_001_cosine_vs_hf_fp16

  F-QW3-MOE-PARITY-001:
    elapsed       = 555.52868ms
    cos_sim       = 0.995384
    threshold     = 0.99
    apr_argmax    = 3555 (val = 22.3671)
    hf_argmax     = 3555 (" What")

  test result: ok. 4 passed; 0 failed; 0 ignored

cos_sim 0.995384 ≥ 0.99 by margin 0.0054. apr_argmax = hf_argmax = 3555
(exact agreement, no near-tie hypothesis needed).

## Five-whys for "60 GB HF download was stale claim"

(1) v1.4.0 (2026-05-02) elevated R9 to "operator-confirm pending ~60 GB
    HF download". Issue #1584 (filed 2026-05-09 from companion repo)
    inherited the stale claim.
(2) Companion M109 (2026-05-09) discovered FP16 weights had been on
    lambda-vector at /mnt/nvme-raid0/models/Qwen3-Coder-30B-A3B-Instruct/
    (57 GB across 16 safetensors shards, Mar 8 timestamps) for ~62 days.
(3) The "operator-confirm pending X" claim aged silently because no
    detector class checks "is X-pending claim still mechanically true?"
    Companion's 12-assert detector covers M-count / gate-count /
    contract-version / fixture-count / status-anchor consistency, but
    not filesystem-state-of-pending-claim.
(4) Future M110-class kaizen on companion side: detector for
    mechanically-checkable "pending" claims.
(5) Root cause: kaizen blind-spot for filesystem-state drift. M109
    leaves M110 as a future detector extension.

## Edits

- `contracts/qwen3-moe-forward-v1.yaml`:
  - metadata.version: 1.4.0 → 1.5.0
  - top-level version: "1.4.0" → "1.5.0"
  - status: ACTIVE_ALGORITHM_LEVEL → ACTIVE_RUNTIME (with new comment block
    citing M109 discharge evidence)
  - amendment_history: prepended v1.5.0 entry with full discharge
    evidence + reproducibility recipe + cross-repo refs
  - implementation_stages.M32d: PENDING → DISCHARGED with discharge
    evidence in description

- `crates/aprender-serve/tests/fixtures/qwen3_moe_fp16_logits_pos0.json`:
  NEW (2.06 MiB) — 151936-dim FP32 logit vector for prompt "What is 2+2?"
  at position 6 (end-of-prompt). Generated 2026-05-09 in 52s wall via
  uv run --with torch --with transformers --with accelerate
  scripts/generate_qwen3_moe_fp16_logits.py
  --model /mnt/nvme-raid0/models/Qwen3-Coder-30B-A3B-Instruct
  --output crates/aprender-serve/tests/fixtures/...
  Committed verbatim per script docstring "this fixture is captured
  once and committed" — makes the discharge reproducible.

## F-QW3-MOE-PARITY-002 sibling status

Deferred — CPU-only `llama-cli` on Qwen3-Coder-30B-A3B-Instruct hung
at 99.9% single-CPU for 2 hrs without producing output even with
`-ngl 999` GPU-offload flag (suspected MoE expert dispatch is
CPU-bound in llama.cpp build #7746 — upstream issue, not aprender-side).

Not load-bearing for ACTIVE_RUNTIME flip: axis (a) directly proved
apr_argmax = hf_argmax = 3555. Test stays #[ignore]-gated for
regression coverage when llama.cpp's MoE-on-CPU performance improves.

## Cross-repo refs

- Companion-repo M109 milestone: paiml/claude-code-parity-apr#95
  squash 9c2833334 (2026-05-09T15:02:33Z)
- Companion-repo M108 ticketing: paiml/claude-code-parity-apr#94
  (filed #1584 with stale "60 GB pending" claim — corrected by M109
  same day)

## Verification

- pv validate contracts/qwen3-moe-forward-v1.yaml: 0 errors / 0 warnings
- F-QW3-MOE-PARITY-001 cosine test: PASS at cos 0.995384
- HF FP16 fixture: 2.06 MiB committed at canonical path
- apr forward: 555ms on 7-token prefill (no regression vs v1.4.0)

Refs PMAT-CODE-QWEN3-MOE-PARITY-FLIP-001.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>