feat(fxe): reproduce the VIEW camera; fxs consumes the framing portion

[jomkz]

Split from #285, re-homed to fxe per the layering: fxe reproduces FA.EXE's signatures — including rendering (the T_/G_ pipeline) and cameras (the VIEW subsystem) — and fxs consumes the portion of that it needs, rather than reinventing a camera per preview. fx_render stays the low-level renderer (Camera = MVP in, pixels out); the camera logic is game code, so it belongs in fxe.

Today each fxs 3D preview (SH model; the #285 T2 terrain viewer) uses an ad-hoc orbit camera — a documented stand-in. The faithful path: reproduce the VIEW subsystem in fxe, expose the framing portion, and have fxs call it.

Reproduce in fxe (the how, from the RE — not the why)

The stateless framing math, driven by asset geometry (a bounding radius) rather than live sim state (docs/fa/view.md, db/symbols/view.csv, #257):

• VIEWFitDistance (0x40E2C0) — camera stand-off from object radius → replaces distance = span * k.
• VIEWBuild / VIEWFromObject (0x40EBC0 / 0x40D810) — the external / spot orbit transform.
• VIEWAngleScale / VIEWScaleClamp — FOV / zoom angle clamping.
• VIEWSlew / VIEWSlewIntegrate (0x40D7A0 / 0x40F2D0) — free-look, mapped to drag input.

Reference the VIEW* symbols with confirmed/inferred markers; numeric constants live in the local Ghidra decompile, so some land as inferred.

Boundary

FA's camera is a gameplay camera coupled to the sim — _objPtrs tracked objects, physics, _mainV state, transitions, the replay recorder. fxs has no sim, so fxe exposes the sim-decoupled framing (radius → stand-off, orbit transform, slew), not the live camera. The view-mode enumeration is an open RE question (#262: cockpit/spot/padlock/flyby/external not fully pinned) — expose only modes with a real static analog.

Per-resource mapping

• SH models → external / spot view (orbit at fit-distance).
• T2 terrain → high external / fly-by framing.
• Cockpit / padlock: no static analog without a sim — leave out rather than fake.

Acceptance

• fxe reproduces the VIEW framing (FitDistance + external/spot orbit + slew), referenced to docs/fa/view.md with confirmed/inferred markers.
• fxs's SH preview and the feat(fx-gui): T2 terrain 3D viewer #285 terrain viewer both consume it; the ad-hoc orbit math is removed.
• gui.md notes the preview camera is fxe's VIEW framing, sim-decoupled.

Related note (rendering half)

The same principle applies to rendering: fxs's terrain_preview mesh build and the SH mesh build are interim; the faithful path is to consume fxe's reproduced T_/G_ pipeline (terrain tessellation T_Make/T_EmitCells, object draw) once fxe ports it. Tracked under the fxe milestone (epic #280).

[jomkz]

Packaging requirement (design intent). fxe doesn't exist yet (ADR-0002 charters it; no fxe/ module today), so this is a recorded target, not near-term work — fxs uses the documented stand-in orbit meanwhile, at zero cost.

The load-bearing constraint for when fxe is built: the consumable form must be a library, matching how fx_lib and fx_render are shared libs that cli/ and gui/ link — not logic baked into an fxe executable. fxs should link the fxe engine library's VIEW module the same way it links fx_render, pulling only the sim-decoupled framing slice (radius→stand-off, external/spot orbit, slew), never the live-sim camera (tracked objects, replay, transitions). Because fxe is greenfield, design this factoring in from day one — cheap now, expensive to retrofit.

Escape hatch: if VIEW's framing can't be cleanly decoupled from the sim inside fxe, promote the slice to a small shared fx_view lib consumed by both the fxe port and fxs — same fidelity, same single source of truth, same established shared-lib pattern. Either way, fx_render stays a pure geometry→pixels renderer with no FA-specific camera modes.