Guard poll() against a mode-apply mid-flight; two doc corrections

Extends the OnTimer guard to skip session.poll() itself while modeApplyInProgress(), preventing an undo/redo or project-switch reload from replacing the view model under an in-flight applyMode.

src/shell/view/CLAUDE.md

@@ -180,7 +180,9 @@ applies the resulting lane state to live tracks.
   pump premise below, and `applyMode` fails closed when re-entered
   (`modeApplyInProgress`). The window that remains is what a call REACHABLE FROM
   a pumped message loop but not routed through `applyMode` could see — no save,
-  no reload and no discard reaches it, and there is no queued intent for an undo
+  no reload and no discard reaches it (`main.cpp`'s `OnTimer` defers
+  `session.poll()` itself, the one caller of `loadFromProject` a re-entered timer
+  could reach, under this same latch), and there is no queued intent for an undo
   to drop. What survives:
   - 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
@@ -256,7 +258,10 @@ applies the resulting lane state to live tracks.
   nothing to fall back on is `main.cpp`'s load glue — it spends a one-shot signal
   — so it tests `modeApplyInProgress` before consuming and retries next tick. The
   action callers just no-op, silently (`reportModeSwitchRefused` speaks only for
-  the transport gate); the user re-fires.
+  the transport gate); the user re-fires. `render_in_place`'s own `applyMode` call
+  is the exception to that recovery path, not to the drop itself: its refusal
+  leaves the membership tags it already wrote in place, so the next reapply — not
+  a user re-fire of render-in-place — is what brings the tracks into sync.
 - `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