Name refused tracks before Undo_EndBlock2, not after; tighten the route-list doc; pin the refusal memo's gate

Fixes D (handle lifetime), C (ASCII dashes), G (comment compression), I (shouldReport extracted + tested); CLAUDE.md route list corrected per A/B/H. E pushed back -- cross-module GUID plumbing is architectural, not a targeted fix.

src/shell/view/CLAUDE.md

@@ -162,16 +162,28 @@ applies the resulting lane state to live tracks.
   never falsely committed — and never finished either, since the refusal skips the
   FX enqueue too. Full contract at `discardDeferredFxParks`.
 - **Which routes actually reach that no-snapshot-plus-parked-chain pair.** An undo
-  of a mode switch is NOT one of them: per the observed undo semantics above, the
-  flags, the FX and the ext-state snapshots all come back at the same step, and
-  stopping short of it leaves the snapshot in place (so the next park is a
-  `ParkOnly`, not a refusal). What remains: a model replaced without the project
-  rolling back with it (an unreadable or absent `view_state` against an `.rpp`
-  saved parked), a snapshot `reconcile` pruned while its track was out of the live
-  enumeration and then undo-restored with the track, and a hand or script edit
-  that leaves a chain park-shaped. A track the USER keeps hidden from both panels,
-  out of the mix and FX-bypassed reads identically to all of them and is refused
-  too — no lost state there at all, which is why the report asserts no cause.
+  of a mode switch (Ctrl-Z) is NOT one of them: per the observed undo semantics
+  above, the flags and the FX come back at the same step. Whether the ext-state
+  snapshot comes back with them is INFERENCE, not observed, and untested in the
+  REDO direction: `[verify — DAW]` does a redo that re-parks a track's flags/FX
+  also restore a `view_state` that is snapshot-free for it (matching a fresh
+  park), or can it re-park the live track while the model still holds a stale
+  snapshot? What is confirmed to reach the pair: a `view_state` that PARSED but
+  carries no snapshot for the track (a snapshot `reconcile` pruned while its
+  track was out of the live enumeration, then undo/redo-restored with the track
+  but not the snapshot), and a hand or script edit that leaves a chain
+  park-shaped — including the single likeliest real case, a track with untouched
+  flags and just ONE hand-offlined plugin (the FX half of the disjunction
+  refuses alone; the flags never have to read parked too). A track the USER
+  keeps hidden from both panels, out of the mix and FX-bypassed reads
+  identically to all of them and is refused too — no lost state there at all,
+  which is why the report asserts no cause.
+  A DIFFERENT strand entirely, which the refusal report does NOT cover: an
+  absent or malformed `view_state` (`loadViewModel`, `ext_state_io.cpp`) is not
+  a parked-chain reading at all — it falls back to a DEFAULT model (active mode
+  Arrange, empty membership), so nothing is planned to park the track,
+  `decidePark` never runs, and a track saved parked stays stuck with no console
+  line whatsoever.
 - `fx_offline`'s identity keying (`TrackFX_GetFXGUID`) assumes the GUID stays
   attached to its plugin across a chain mutation while parked. That is
   `[verify — DAW]` (see `fxGuidString` in `view_fx_park.cpp`) and SWS issue #802 is a