fpaudit campaign: final regression and state of the ground
==========================================================
Full-battery regression of every surviving spec against the final
tree (all accuracy options on for their respective processors):

  VU: fused adversarial, MADDA battery, flag battery, decomposition
      probe, lower batteries 2/3, memory battery, original lower and
      upper censuses -- 13 batteries, 67,600 case-rows total.
  EE: arithmetic census, battery 2 (converts/compares/branches/
      moves/memory), CVT full-range, CTC1 round-trip.

  GENUINE DIVERGENCE: ZERO ROWS.

Three non-zero raw counts, each attributed and understood:
- Lower batteries re-compared with raw VI16/17/18 included show the
  known representation classes (rec status-instance round-trip
  stickies, R storage format) -- architecture-equal, proven via
  observed reads in their original arcs; the regression comparator
  was stricter than the verdict methodology.
- OPMSUB at 600/600 traced to the SPEC, not the recompiler era
  (identical on the pre-fused binary): the census encoded dest=0xF
  on an xyz-only outer-product op. The interpreter ignores the
  architecturally invalid w bit; the recompiler honors it and
  computes the lane. Undefined-encoding divergence -- assemblers
  cannot emit it -- recorded, not fixed.

The measured state this closes over:
- VU values: all FMAC (ADD SUB MUL MADD MSUB MADDA MSUBA),
  comparisons, i-forms, full lower table, Q pipeline -- bit-exact
  under EnableVuAccurateAddSub + EnableVuExactMul (+ExactDiv for Q)
  on the adversarial distribution, raw exp-255 operands and
  saturating products included, with the hardware fused-MAC
  overflow rule implemented from the model's source.
- VU flags: status and mac at zero across the measured family via
  the saturation-event export; the O-detect block now exists
  outside the overflow gamefix.
- EE: soft-float and accurate-arith complementary and fully
  mapped; ABS/NEG and CVT.S.W closed under the options; compares,
  moves, memory, branches exact; per-op prices complete
  (accurate: +2ns-class on add/mul; soft: 131-156ns divide family).
- Prices, VU: accurate addsub 5-8ns/op, exactmul 9-10ns/op,
  defaults 0.2-2ns.

Open items, none rig-side:
- Hardware minutes: CFC1 garbage round-trip (decides interp-vs-rec
  readout construction); FMAX*FMAX MADD capture (confirms the
  model's fused rule); EFU sweeps by census tier.
- Maintainer decisions: option promotion/defaults, the overflow-
  hack fusion question, savestate treatment of the representation
  classes.

Default-accuracy decision (maintainer policy: as accurate as
possible without losing the current performance budget), measured
on real game workload (Tekken, 300-600 frame runs, best-of-three,
host-bound so relative deltas are the signal; base best 16.43):

  EE FpuAccurateArith   best 16.92  -- WITHIN NOISE (beats base's
                                       best) -> PROMOTED TO DEFAULT
  VU AccurateAddSub     best 15.72  -- about -4%, at the noise
                                       edge  -> stays opt-in
  VU ExactMul           ~13.5       -- about -18%  -> stays opt-in
  VU ExactDiv           best 13.71  -- about -17% robust across all
                                       reps -> stays opt-in
  all four together     10.39       -- about -37%; the max-accuracy
                                       preset territory

The promotion flips three sites together (Pcsx2Config default,
libretro core-option default string, and the core's cached setting
initial) so config and frontend agree. New-default rig outputs are
byte-identical to old accurate-mode outputs, and new-default frame
throughput lands at the top of the baseline range.

Finding banked with the numbers: ExactDiv's 17% cost cannot be
per-Q-op (Q ops are a small fraction of the stream) -- it is
per-block or thunk overhead, which makes it a concrete future
optimization target that could change its verdict.

Overflow-detection promotion (question 2, maintainer-approved):
the detect block's config gates are dropped -- overflow flags are
now set in every mode, mul-family scoped by the class gate, with
the threshold detector in default mode and the exact pattern/event
machinery under the accuracy options. Deciding measurements: the
block is free on frame throughput (three reps, dead even), and the
old-vs-new default diff is EXACTLY the O-bit columns -- 1,874
adversarial rows gain O bits, zero rows change anything else, and
300 frames of default pixels are identical. Default-mode flag
accuracy vs the oracle moves from always-wrong (rec-O identically
zero) to MUL 9/400 and fused 125-139/400 adversarial (from
370-379). The VuOverflowHack GameDB entries are harmless no-ops
from this commit; the config plumbing stays intact.

VuOverflowHack retirement (follow-up to the promotion): the arm64
detect block still gated on the flag -- the promotion commit had
not mirrored -- so the mirror lands first (arm64 carries the
threshold detector; the exact pattern/event machinery under the
accuracy options is x86-only, recorded on the arm64 accuracy-parity
ledger alongside the fused blends). With both recompilers
unconditional, CHECK_VUOVERFLOWHACK has zero consumers and the
macro is deleted; the config bit and the "VUOverflow" GameDB name
remain parsed-and-ignored, marked deprecated, so every existing
GameDB file and user config stays valid. x86 build and the arm64
cross syntax gate on the including TU both clean.

ExactDiv overhead investigation (the banked optimization target,
resolved): the all-sixteen-xmm ABI-paranoid thunk was replaced by
the field-proven XGKICK idiom -- mVUbackupRegs(onlyNeeded) saves
only the allocator's cached caller-saved registers with the same
stack and shadow-space discipline, MXCSR round-trip kept as cheap
insurance -- and the stub machinery deleted. Correctness gates:
DIV, SQRT, RSQRT all 0/400 under exactdiv on the lower battery;
default emission untouched by construction (all changes inside the
option gate). Measured gain: about two percent of frame throughput
(best-of-three 13.65 to 13.91).

Why only two: a call-counter probe measured 87,000 Q-ops per frame
on the Tekken workload -- roughly 126ns per call post-optimization
against an 11ms/frame deficit -- so the cost is frequency times the
serial digit-recurrence chain, whose SSE lane form was already
tried in an earlier arc and measured slower while bit-exact. The
seventeen percent is algorithm-bound at fighting-game Q frequency,
not overhead-bound: ExactDiv's opt-in verdict is confirmed rather
than reopened, and the remaining theoretical headroom (zeroing all
call overhead) is bounded near eight percent for anyone who wants
to chase inlining the digit chain into emitted code.
