…vs-gpu-output-parity-v1` chain (PRs #1427-#1430) (#1431)

Canonical record of today's 4-PR session that lands a 3-layer jidoka armor
at the GPU-CPU dispatch boundary, closing §40's silent-gibberish loophole
*as a regression class* (separate from the underlying GPU kernel fix).

Net effect: default `apr run <model.apr>` on a SHIP-007-broken GPU build
now emits the full backend-fallback chain on stderr without `--verbose`:

  [apr-cpu-vs-gpu-output-parity-v1] CUDA path rejected, attempting fallback: ...
  Backend: wgpu (Vulkan)
  ...

so users always know which backend is actually serving their tokens — the
`--no-gpu` documented workaround is now self-evidently the correct path on
this build. MODEL-1 ship % nudges 80% → 87% because shipping `apr run` users
with the documented workaround is now jidoka-safe.

This section explicitly does NOT claim the SHIP-007 kernel bug is fixed —
that remains an open track per §40. What §41 codifies is that the failure
mode is now LOUD instead of SILENT.

Five Whys + table of all 4 PRs + next-session pickup list (FALSIFY-CPU-GPU-005
part b OR MODEL-2 distill-train scaffolding) included.

Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>

… drift-prevention tests (#1435)

Closes the contract drift between v1.2.0's prediction and the actual code:
contract `apr-cpu-vs-gpu-output-parity-v1` v1.2.0 (PR #1430) said the wgpu
rejection log should emit `[apr-cpu-vs-gpu-output-parity-v1] wgpu path
rejected, attempting fallback: ...` symmetric to the CUDA tag, but #1430
only made the existing `[GH-559]`/`Backend:` logs unconditional — the
contract-tagged wgpu rejection log itself was missing.

Mirror of the FALSIFY-CPU-GPU-003 chain (#1428 visibility + #1429 drift
test) for FALSIFY-CPU-GPU-005:
- Adds `pub(crate) const WGPU_FALLBACK_LOG_PREFIX = "[apr-cpu-vs-gpu-output-parity-v1] wgpu path rejected"`
- Updates `try_apr_wgpu_inference` to emit it on `GpuDevice::new()` failure
  (alongside the existing `[GH-559]` runbook tag — both, not either)
- 3 new unit tests:
  * `wgpu_fallback_log_prefix_is_contract_tagged` (symmetric to the CUDA test)
  * `cuda_and_wgpu_fallback_log_prefixes_share_contract_tag` (symmetry guard:
    both prefixes must start with the same contract ID and end with
    "path rejected" so grep recipes work uniformly across backends)

Five Whys:
1. Why was this gap in v1.2.0? PR #1430 conflated "make existing wgpu log
   visible" (done) with "add contract-tagged rejection log" (deferred). The
   contract's prediction text wrote the second; the code shipped only the
   first.
2. Why catch it now? `--features hub` build healthy across PRs #1432-#1434
   means the test surface is reliable; this is the natural follow-up.
3. Why the symmetry test? `cuda_and_wgpu_fallback_log_prefixes_share_contract_tag`
   locks in that BOTH backends use the same `[CONTRACT_ID] <backend> path
   rejected` shape. Without it a future PR could drift one but not the
   other and grep recipes would silently skip backends.
4. Why keep `[GH-559]` alongside the new contract tag? Runbook continuity
   — humans tracking that issue tag in logs over time shouldn't lose it.
5. Why no contract version bump? v1.2.0 already specifies this tag in
   FALSIFY-CPU-GPU-005's prediction; this PR closes the implementation
   gap. Bumping again would imply a contract semantic change, which
   isn't happening — only the code catches up to the contract.

Verified locally:
- `cargo test -p aprender-serve --features cuda --lib --release fallback_log_prefix`
    → 3/3 pass (cuda + wgpu + symmetry)
- `cargo fmt --all -- --check` → no diff in touched file

Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>