#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

game/reconstructed/myomers.cpp

@@ -772,14 +772,23 @@ void Myomers::MyomersDriveHeat(Scalar time_slice)
 	// the ApplicationManager ctor (0x401189: push [0x52140c]).  So the pod's
 	// nominal Performance cadence was 28 Hz, byte-proven.  [T1]
 	//
-	// CALIBRATION FACTOR 0.5, testimony (Oracle, 2026-08-02): at the byte rate
-	// the veterans still report ~2x too much myomer heat -- "If you could
-	// please halve the myomer heat rate again.  We will bracket to something
-	// reasonable."  The plausible physical story is the pod's EFFECTIVE rate
-	// under load (a 486 host missing beats; the 18.2 fallback existing at all
-	// says slow paths were expected), which statics cannot settle.  Effective
-	// default therefore 28 * 0.5 = 14 Hz, explicitly marked testimony-
-	// calibrated [T3]; BT_MYO_HZ=<hz> overrides absolutely for bracketing.
+	// CALIBRATION FACTOR 0.5 -- the pod's EFFECTIVE rate under load, now
+	// corroborated from three directions (2026-08-02):
+	//   * Oracle (pod veteran), asked if the 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's own pacer DESIGN: end_of_frame = Now() + frameDuration
+	//     with background fill and NO overrun catch-up (APPMGR.cpp, T0) --
+	//     "target 28 but allowed to slip" is the construction, and the
+	//     18.2065 BIOS fallback anticipated degraded timing.
+	// Corollary: a choking 486 generated LESS heat/s exactly during the
+	// biggest fights -- veteran memory of seek-4 endurance encodes the LOADED
+	// rate, so bracketing by their consensus is the correct instrument.
+	// Effective default 28 * 0.5 = 14 Hz [T2 multi-witness]; BT_MYO_HZ=<hz>
+	// overrides absolutely for bracketing.
 	static const Scalar kPodFrameHz    = 28.0f;	// byte-proven nominal [T1]
 	static const Scalar kSeekHeatCalib = 0.5f;	// Oracle bracket 2026-08-02 [T3]
 	static Scalar s_hz = -1.0f;