…es Q8K activation quant, CUDA uses f32 — different algorithms (#1583 PR-3l DISCHARGE)

Seventh falsifier in M-GPU-MOE-3 cascade. Bisects #1821's 5% Q4_K
divergence by comparing THREE paths on identical Q4_K bytes:

A = CPU fused_q4k_parallel_matvec      (production-MoE path)
B = CPU dequantize_q4_k_to_f32 + naive_f32_matvec (isolates dequant)
C = CUDA q4k_matvec                     (suspected broken in #1821)

## EMPIRICAL RESULT — INVERTS #1821

           pair      rel_diff         1-cos
   A vs B (CPU)      2.883e-2      7.093e-6   ← CPU fused ≠ CPU dequant
A vs C (CPU-GPU)      2.883e-2      7.033e-6   ← CPU fused ≠ CUDA
B vs C (deq-GPU)      5.028e-7     -1.192e-7   ← CPU dequant ≈ CUDA ✅

**CUDA q4k_matvec is CORRECT.** Path B (manual CPU dequant + naive
f32 dot) matches path C (CUDA) to ulp-scale 5e-7.

**CPU fused_q4k_parallel_matvec is the divergent path.** It
disagrees with BOTH the CPU naive-dequant reference AND CUDA by
the SAME 2.88% delta.

## True root cause — CPU pre-quantizes activations

parallel_k.rs:181-182 docstring confirms:
  'Pre-quantizes f32 activations to Q8_K once per matmul, enabling
   integer-only inner loops (maddubs) for ~4-8x speedup'

So:
  CPU fused_q4k_parallel_matvec  = Q4_K(W) × Q8_K(quantize(f32_act))
  CUDA q4k_matvec                = Q4_K(W) × f32_act       (no quant)

**They compute DIFFERENT MATHEMATICAL OPERATIONS.** The 2.88%
per-matvec delta is the lossy Q8_K activation quantization.

## What this means for M-GPU-MOE-3 (#1583)

The 0.94-cos drop on real Qwen3 L7/L9/L12/L20/L23/L29/L46 is
**NOT a kernel correctness bug**. It is the natural compositional
consequence of CPU using Q8K activation quant while CUDA uses f32
activations. 2-3% per-matvec compounds across 128 experts × 48
layers to produce the observed ~6% cumulative drop.

#1583's original framing (kernel-level reduction-order alignment
in Q6_K) was triple-wrong: not reduction-order, not Q6_K, not
kernel-correctness. The actual issue is an **activation-qtype
algorithm mismatch** between CPU and CUDA Q4_K paths.

## Fix paths (multi-week, M-GPU-MOE-3 fix scope)

OPTION 1: CPU uses f32 activations (match CUDA)
  - Add fused_q4k_f32_parallel_matvec (no Q8K step)
  - Slows CPU (loses maddubs 4-8× speedup)

OPTION 2: CUDA uses Q8_K activations (match CPU) — RECOMMENDED
  - Add Q8_K activation quant before q4k_matvec
  - Could be FASTER on GPU via DP4A integer ops on Ampere+
  - Modest CUDA kernel scope

OPTION 3: Accept divergence — relax contract cos threshold
  - Update qwen3-moe-forward-gpu-v1 to cos≥0.93
  - Cheapest

## Full cascade discharge

Seven falsifiers, six wrong hypotheses, one true root cause:

  #1801 Q6_K synthetic reduction-order      → ulp-scale
  #1805 activation distribution             → flat
  #1811 chain length compounding            → flat
  #1816 Q6_K real weights + qtype-mix       → ulp-scale + L7/9/12 are Q4_K
  #1818 SwiGLU intrinsic precision          → ulp-scale
  #1821 Q4_K real weights (CPU as truth)    → 5% — misattributed CUDA
  THIS  Q4_K bisection                      → CPU has Q8K quant step

## What this PR ships

- tests/falsify_q4k_bisect_dequant_007.rs — three-path bisection
  (~330 LOC), 1 #[ignore] integration test (2.2s on RTX 4090) +
  5 unit tests.

Per feedback_test_methodology_can_fake_bugs.md — this PR is the
textbook case of why bisection beats single-comparison parity tests.
#1821 used the CPU as ground truth without verifying the CPU was
implementing the same operation as CUDA.

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

…tion