#84: missiles ACCELERATE like the binary -- the pool flew at constant

rack-eject speed; the authored MissileThruster was never applied

The binary Missile hosts a MissileThruster subsystem: authored
acceleration for BurnTime seconds after the MuzzleVelocity eject.
Authored values decoded from BTL4.RES (type-15 missile model records,
reached from the AmmoBin's ammoModelFile via the type-1 MODELLIST
indirection): SRM 2.5s @ 600 u/s^2, LRM 10s @ 300 (climb 50), Streak
3s @ 300 (turn 360deg/s), NARC 10s @ 300; splash 30 all (port constant
was already right); authored drag ~0.001 = negligible.

The port pool flew every round at CONSTANT |MuzzleVelocity| -- SRMs 100
u/s, LRMs 30 u/s (10x slower than authored) -- the entirety of the
night-7 "missiles are very slow" report, and the driver of the
"explosion before the missiles arrive" perception (the salvo-lead
detonates while the slow spread rounds straggle in).

Fix: BTMissileThrustOf (mech4.cpp) lazily parses + caches the RES
thruster table (ModelList ids aliased to their type-15 member's
burn/accel); both launch paths (master FireWeapon + the replicant salvo
mirror -- peers see the same speed) resolve through the launcher's bin
and pass burn/accel into the pool; the advance integrates speed +=
accel*dt while burn remains, heading preserved.  Ballistic rounds
(autocannon/gauss) pass 0/0 -- unchanged.  Impact log now prints
v=/burnLeft= evidence.

Verified live (solo, BT_SPAWN_ENEMY + BT_AF_MISSILE): thrust table 8
entries cached; Black Hawk Streak resolve burn=3 accel=300; impacts at
v=277 u/s (was a constant 100).  Fun authenticity note: the Black
Hawk's "SRM6" fires strk (STREAK) ammo per its authored bin.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019Zh7PTkFy4KwTzVighLR9J

context/combat-damage.md

@@ -359,6 +359,23 @@ Band effects: `MechDeathHandler::Tick` fires the CURRENT band descriptor on any
 (the binary's changed-flag semantics, workflow-verified) — a damaged mech under fire smokes/
 burns per hit; the earlier crossing-only gate was over-tight (the metronome was SHKWAVE).
 
+## Missile THRUST -- FIXED (2026-07-31, issue #84) [T1 values / T2 verified]
+The binary Missile hosts a **MissileThruster** subsystem: the round leaves the rack at the
+launcher's authored MuzzleVelocity (SRM eject 100 u/s flat; LRM 30 u/s up-tilted) and then
+ACCELERATES while BurnTime remains.  Authored values (BTL4.RES type-15 missile model records
++0x44/+0x48, reached from the AmmoBin's `ammoModelFile` through the type-1 MODELLIST
+indirection): **SRM 2.5s @ 600 u/s² (turn 120°/s) · LRM 10s @ 300 (turn 60°/s, climb 50) ·
+Streak 3s @ 300 (turn 360°/s) · NARC 10s @ 300**; SplashRadius 30 for all (the port's constant
+was right); authored drag ~0.001 = negligible.  The port pool flew at CONSTANT eject speed --
+LRMs 10× slower than authored -- which was the whole of the field "missiles are slow" report,
+and the "explosion before the missiles arrive" perception (the salvo-lead detonates while the
+slow spread rounds straggle).  Fixed: `BTMissileThrustOf` (mech4.cpp) lazily caches the RES
+thruster table (ModelList ids aliased to their type-15 member); both launch paths (master fire
++ the replicant salvo mirror) pass burn/accel into the pool, whose advance integrates
+`speed += accel·dt` while burning.  Verified live: Streak impacts at 277 u/s (was 100).
+Note: the Black Hawk's "SRM6" fires **strk** (Streak) ammo per its bin -- the ammo model, not
+the launcher name, decides the flight profile.
+
 ## Ballistic damage type -- FIXED (2026-07-23, issue #27) [T2]
 Playtest matchlog forensics (2,591 applied-damage events over 2 rounds): the damageType
 histogram had Collision/Explosive/Laser/Energy but **Ballistic (type 1) NEVER appeared**,