fix(camera): activate the spring arm with the third-person rig

Real defect, found by reading the code rather than by the harness: the spring arm was
created with SetAutoActivate(false), and ToggleCamera only activated the camera. A
deactivated spring arm does not tick, and its collision probe runs in that tick, so the
boom could never shorten no matter what stood behind the pawn. ToggleCamera and BeginPlay
now activate the arm alongside the camera.

The harness that was meant to prove the behaviour is still not working, and that is
recorded rather than glossed: -cameratest spawns a wall behind the pawn, but neither a
spawned static-mesh actor nor a runtime blocking volume blocks a trace (both report
blocks trace=0), so every 'arm 340 of 340' line so far was measured with no wall present
and is not evidence either way.

TODO.md

@@ -13,11 +13,11 @@ Actionable task list for this project. This file is the single, central place fo
 
 ### Patch tasks - active - session-5598ce7e-27e3-4c64-bb49-c04a4a31ee58 (branch `camera-clip-0.2.3`)
 
-- [A] Fix remaining camera clipping cases in `0.2.x`. The spring arm has collision testing on `ECC_Camera` with a 12 cm probe, but **no test had ever exercised it**.
-  - **Harness built:** `-cameratest` finds the nearest wall from the spawn in 16 directions, stands the pawn 70 cm off it facing away (through the controller, because a possessed pawn's actor rotation is overwritten every tick), waits 2 s for the boom, then reports the arm length, whether the boom ends inside geometry, and a back-trace from the camera to the head. It also requests a screenshot so the placement can be checked by eye.
-  - **Inconclusive so far, and the setup is the suspect, not the engine.** Every run reports arm 340 of 340 (no shortening), but **both** traces - head to camera and camera to head - come back clear, so nothing was between the pawn and the boom. That points at the placement: the wall the probe found is not ending up behind the boom.
-  - **Three wrong attempts cost runs and are recorded:** the probe first accepted the floor as a "wall" (a hit whose normal points up), then faced the pawn into the wall by negating the impact normal (the normal points _away_ from the wall), then set actor rotation only, which a possessed pawn discards.
-  - **Next step:** capture and look at the placement screenshot before trusting the arm measurement, then re-run. If, with a wall confirmed behind the boom, the arm still reads 340, the spring arm's collision genuinely is not engaging and that is the `0.2.3` fix.
+- [A] Fix remaining camera clipping cases in `0.2.x`. **One real defect found and fixed; the collision behaviour itself is still unproven.**
+  - **Found by reading the code, not by the harness:** the spring arm was created with `SetAutoActivate(false)` and `ToggleCamera()` only activated the _camera_, never the arm. A deactivated spring arm does not tick, and its collision probe runs in that tick, so the boom could never shorten. `ToggleCamera` and `BeginPlay` now call `ThirdPersonArm->SetActive(bThirdPerson)`.
+  - **The measurement that was supposed to prove it does not work yet.** `-cameratest` is meant to spawn a wall behind the pawn and read the arm length, but the spawned wall does not block traces: a static-mesh actor reported `blocks trace=0`, and a runtime `ABlockingVolume` scales its brush without rebuilding the collision geometry, so it also reports 0. Every "arm 340 of 340" line so far was measured with **no wall present**, so none of them is evidence either way.
+  - **Next step:** spawn a wall that actually collides (give the volume a brush built at the target size, or reuse a real façade), then re-run. Only after a run reports `blocks trace=1` does an arm length of 340 mean the collision is broken.
+  - **Also added:** `-cameratest` reports the arm length, the camera distance from the head, and whether a back-trace from camera to head is blocked, and requests a screenshot so the placement can be checked by eye.
 - [ ] Tag `v0.2.3` and write `CHANGELOG.md` entry; then remove this section.
 
 ## 0.3.0 — Chaos vehicle, enter/exit, closed driving route (weeks 10–13)