wreck smoke dies WITH the wreck; the audio/effect clock is calibrated to the byte-proven 28

USER REPORT: "when you destroy a mech, it continues to smoke for a very long
time after the mech disappears... up to 30secs to a minute."

MEASURED (new [pfx] timed census with per-def particle attribution): the
death plume (psfx 1 DDTHSMK) was re-armed on a 10s cadence as a WORLD effect
(ownerTag=0) -- so neither the burial transition nor the respawn cleanup
(StopAllEntityEffects) could touch it.  The last-armed window kept emitting
over the empty spot for up to 10s after the hulk vanished, plus 6+-2s authored
particle lives, and back-to-back windows stretched the visible tail to the
reported range.  The re-arm itself is a marked PORT ADDITION [T3]; the binary
fired DDTHSMK once -- its 10s window + particle lives ended right around the
~17s hulk sink.  The authored design: the smoke dies WITH the burial.

FIX: the plume is spawned ATTACHED (BTStartPfxAttached, tagged to the dying
entity -- it also rides the sinking hulk now), and the burial transition calls
BTStopEntityPfx alongside the respawn cleanup that already did.  Verified over
a 175s run containing FOUR wreck events (the enemy kill + three player bay-
fire deaths): every plume's emission ends at its wreck's burial or respawn,
particles fade within ~8-11s, no orphan emitters remain.

THE COUPLING (user relay of Oracle: "prolonged smoke and explosion INCLUDING
SOUND... same lever?") -- CONFIRMED as a family: the binary's audio layer
times in FRAME COUNTS converted by the engine frame-rate global:
    AudioTime::Seconds_To_Frames == fmul [0x52140c]=28.0; fadd 0.5; round
    (@0x42c611, @0x42dd86 -- the 0x42xxxx cluster of the ~90 global consumers)
Our engine's DefaultRendererRate said 30: every audio duration, sequence
delay and compression window ran ~7% fast.  Calibrated to 28 [T1].  NOT yet
explained by this: a truly SUSTAINED/looping explosion sound (7% is not
"prolonged") -- the effect stop-path trace stays open on #114/#51.

Tooling: BTPfxParticle carries defIndex; [pfx] census (BT_PFX_LOG, 2s) prints
emitters + particles PER EFFECT SLOT with a timestamp; wrecksmoke.sh.

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

context/decomp-reference.md

@@ -560,6 +560,15 @@ and passed straight into the ApplicationManager ctor by the DOS main
 whenever the decomp shows an unexplained multiply/divide by `_DAT_0052140c`,
 it is per-second <-> per-frame conversion at the pod's 28 Hz.
 
+**The AUDIO/EFFECT FRAME CLOCK is this same rate.**  `AudioTime::
+Seconds_To_Frames` in the image is `fmul [0x52140c]; fadd 0.5; round` (e.g.
+@0x42c611, @0x42dd86 — the 0x42xxxx audio-layer cluster of the ~90 consumers),
+so every authored audio duration/delay counts frames at 28.  WinTesla's
+`DefaultRendererRate` said **30** — all audio timing ran ~7% fast until
+corrected (2026-08-02).  Oracle's coupled report ("prolonged smoke and
+explosion including sound") was the lead: effect visuals and audio share this
+clock family.
+
 **So the pod's nominal simulation cadence was 28 fps, not the i860 board's
 30 Hz — and it was UNLOCKED.**  Corroborated testimony (2026-08-02): Oracle —
 the pod rate was "flipbook" territory, heavy fights "a slide show"; Lynx