#96: the effective-rate theory is corroborated -- upgrade the calibration provenance T3 -> T2

Frame-rate testimony from the morning follow-up, now on record beside the bytes:
  * Oracle, asked if the pod frame rate was rock solid: "I think I could do as
    well with a flipbook"; heavy fights "would turn to a slide show".
  * Lynx (original era): "RP had a target frame rate of 30FPS.  It wasn't hard
    coded or locked.  BT never had a locked frame rate in 1st release
    testing... coming from 3.0, where 20FPS was a miracle."
  * The engine pacer's own design agrees: fixed budget + background fill + NO
    overrun catch-up (APPMGR.cpp, T0) = "target 28 but allowed to slip", with
    the 18.2065 BIOS fallback anticipating degraded timing.

Also settles epilectrik's open confirmation ("frame rate is advancing at least
some of the subsystems -- i have to fully confirm that"): ALL of them --
UpdateManager::Execute runs every interesting master every frame,
Entity::PerformAndWatch runs every executable subsystem per entity tick, no
throttle at any layer.  The crisp rule: CADENCE is frame-linked for
everything; only terms missing a dt multiply are rate-SENSITIVE.

Corollary worth keeping: a choking 486 generated LESS heat/s exactly during
the biggest fights -- the slideshow was mercy.  Veteran memory of seek-4
endurance encodes the LOADED rate, which is why bracketing by their consensus
is the correct instrument rather than a concession.

Follow-up filed in the KB: sweep the reconstruction for OTHER dt-less per-tick
accumulators (known: particle trail density, rendering.md; the 15-sample
heatFilter window is rate-dependent smoothing, benign).  Each found one should
normalize against the same 28-nominal/bracketed-effective pair.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

context/decomp-reference.md

@@ -561,7 +561,14 @@ whenever the decomp shows an unexplained multiply/divide by `_DAT_0052140c`,
 it is per-second <-> per-frame conversion at the pod's 28 Hz.
 
 **So the pod's nominal simulation cadence was 28 fps, not the i860 board's
-30 Hz.**  Every "per tick with no dt" accumulation in the binary (the myomer
+30 Hz — and it was UNLOCKED.**  Corroborated testimony (2026-08-02): Oracle —
+the pod rate was "flipbook" territory, heavy fights "a slide show"; Lynx
+(original era) — "BT never had a locked frame rate in 1st release testing",
+RP targeted 30, Tesla 3.0 managed ~20 on a good day.  The engine pacer design
+agrees: fixed budget, background fill, NO overrun catch-up (APPMGR.cpp T0) —
+target 28, allowed to slip.  Consequence: any per-tick dt-LESS accumulator ran
+SLOWER during heavy combat on real pods; per-tick behaviors must be calibrated
+against the loaded effective rate (veteran bracketing), not the constant.  Every "per tick with no dt" accumulation in the binary (the myomer
 kinetic heat term; candidate: particle trail density) was calibrated against
 28 nominal — and less under load (the 18.2 fallback existing at all says slow
 paths were expected; the EFFECTIVE in-pod rate is an open question, see