Implement the translocation sphere -- the "blue warp" respawn effect (task #52)

BTTranslocationRenderable was a no-op stub; now reconstructed over the engine's
POVTranslocateRenderable: loads tsphere.bgf and runs a collapse-on-arrival /
expand-on-reveal sphere (scale 100->1 over 1.3s, then 1->150 over 1.0s, rotating)
keyed on the player's SimulationState dial. Drawn direct from the render loop by
BTDrawTranslocationSpheres (beside BTDrawBeams, PASS_ALPHABLEND) -- the same
accommodation the beams/reticle use.

The asset loads by FILENAME (tsphere.bgf), not through the RES table -- which is
why every resource-name search missed the effect for three rounds.

Trigger wiring: btl4vid.cpp MakeEntityRenderables builds the sphere for the LOCAL
player (the authentic wiring builds it only for replicants + a POV fade for self,
but peer player-attribute replication isn't wired -- on a replicant SimulationState/
DropZoneLocation read uninitialised). btplayer.cpp pulses SimulationState
DropZoneAcquired->VehicleTranslocated at respawn (a 1.4s flip timer stands in for
the engine's +1s drop-zone re-post) and writes the respawn origin into the
DropZoneLocation attribute.

Verified 2-node (BT_TLOC_LOG): on respawn the sphere collapses (~100->5) then
expands (->150) at the valid drop-zone origin, deduped to <=2 active, respawn
cycle un-regressed, no render errors. Visual appearance (colour/size) still needs
a live look; the authentic see-others'-spheres path needs player replication.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

context/multiplayer.md

@@ -221,11 +221,23 @@ transition, HUD all landed since P6): console egg → mesh → RunningMission on
      1)` (FUN_00458d2c, alloc 0x40, control state 1); our own POV instead gets `BTPOVStartEndRenderable`
      (the mission fade in/out). So peers watch each other's translocation sphere; your own death is a
      POV fade.
-   - **Why unseen:** `BTTranslocationRenderable` (declared btl4vid.hpp:320) is a NO-OP STUB in
-     `btstubs.cpp:365` (`: BTRenderableBase(entity) {}`). Porting it = reimplement over the engine's
-     `POVTranslocateRenderable` (its `d3d_OBJECT::LoadObject("tsphere.bgf")` + Execute state machine are
-     already in L4VIDRND.cpp; the DPL instance/DCS calls are commented — render via our d3d_OBJECT +
-     Scene renderable path, same infra as the beam/reticle renderables). TODO — task #52 whirlwind visual.
+   - **✅ DONE + LOG-VERIFIED (2026-07-09, task #52):** `BTTranslocationRenderable` was a no-op stub
+     in `btstubs.cpp`; now reconstructed in `btl4vid.cpp` (state machine + `d3d_OBJECT::LoadObject
+     ("tsphere.bgf")`), drawn direct from the render loop by `BTDrawTranslocationSpheres` (hooked in
+     L4VIDEO.cpp beside `BTDrawBeams`, PASS_ALPHABLEND) — the same direct-draw accommodation the beams/
+     reticle use since our VideoComponent tree is partial. Trigger: the LOCAL player's own
+     `SimulationState` dial, pulsed `DropZoneAcquired(1)`→`VehicleTranslocated(2)` at respawn (btplayer.cpp
+     create branch + a 1.4 s flip timer in `PlayerSimulation`), with the respawn origin written into the
+     player's `DropZoneLocation` attribute (the sphere's draw position). Wiring (btl4vid.cpp
+     `MakeEntityRenderables`, BTPlayerClassID) originally built the sphere only for REPLICANT players
+     (third-party view) + a POV fade for self; extended to build it for the LOCAL player too, since peer
+     player-attribute replication (SimulationState/DropZoneLocation) isn't wired (on a replicant both read
+     0xCD… uninitialised — confirmed via `BT_TLOC_LOG`). Verified 2-node: on B's respawn the sphere
+     COLLAPSES (scale ~100→5) then EXPANDS (→150) at the valid drop-zone origin, deduped to ≤2 active,
+     respawn cycle un-regressed, no render errors. Env gate `BT_TLOC_LOG`. REMAINING (follow-up): the
+     visual appearance (colour/translucency/size on screen) is unverified by logs — needs a live look;
+     and the AUTHENTIC peer path (see OTHERS' spheres) needs player SimulationState/DropZoneLocation
+     replication — until then the local-player sphere stands in.
    NOTE the respawn-cycle SIM path is separate + done: `DropZoneReply` (FUN_004bffd0) → `Mech::Reset`
    (@0049fb74) + the level-2 "translocated" cockpit alarm; `CreatePlayerVehicle` (FUN_004bfcac,
    disassembled — make+link only, matches RP analog). The sphere is a pure RENDER-side watcher on the