view: split the deferred FX-park drain by kind — restores stay forced, parks go one FX per idle tick behind a 1s coalescing delay

A rapid A→B→A flip now costs no plugin work: the restore cancels the still-pending
park outright. A park that has already written one FX carries a `partial` flag and is
superseded by its inverse rather than cancelled, so a half-parked chain is never stranded.

src/shell/view/CLAUDE.md

@@ -54,14 +54,23 @@ decide membership or mode rules.
   lost. What it does change is the undo record: the offline writes land outside
   the switch's undo block, so the tool no longer re-drives them on an undo or a
   redo — what a Ctrl-Z then leaves the chain at is REAPER's own FX-state record,
-  `[verify — DAW]`. **The idle tick is not the only drain point.** Any path that
-  serializes the view model drains synchronously first (`persistViewState`,
-  `render_in_place`), because a save landing between a restore's synchronous flag
-  writes and its drain would record offline FX beside a model that no longer
-  carries the snapshot to replan them — unrecoverable on reopen. So an
-  action-driven switch does pay the FX hitch before it returns; the repaint and
-  the undo block have both closed by then, which is what the deferral was for.
-  Any new caller that reapplies a mode and then persists inherits this obligation.
+  `[verify — DAW]`. **The drain is SPLIT BY INTENT KIND, because only one kind is
+  unsafe to persist over.** A pending RESTORE is: flags restored, snapshot already
+  dropped, FX still offline — a save inside that window records offline FX beside a
+  model that can no longer replan them, unrecoverable on reopen. So any path that
+  serializes the view model drains every restore synchronously first
+  (`persistViewState`, `render_in_place`), and an action-driven switch still pays
+  the RELOAD hitch before it returns — its repaint and undo block have both closed
+  by then, which is what the deferral was for. Any new caller that reapplies a mode
+  and then persists inherits this obligation. A pending PARK is safe to save over:
+  flags parked, snapshot stored, FX still online, so a reopen replans the park and
+  the drain offlines it — it converges. Parks therefore go lazy, ONE FX per idle
+  tick behind a one-second coalescing delay, so the unload half never blocks the
+  UI at all. The delay is also the width of the live-enumeration hazard at
+  `tickDeferredFxParks` — do not lengthen it casually.
+  `[verify — DAW]` whether the switch's `UpdateArrange` paints before the first
+  drain tick: nothing pumps the message loop between them, so "the switch paints
+  first" is an assumption, not an SDK guarantee.
 - **Stated DEVIATION — the undo mask does not keep FX out of a real switch.** The
   apply mask (`kApplyUndoMask`) drops `UNDO_STATE_FX` and ORs it back in when a
   driven flag in that domain moved; the only such flag is `I_FXEN`, which every
@@ -107,7 +116,7 @@ applies the resulting lane state to live tracks.
 ## Modules
 
 - `view` — Design View shell: snapshots flag values before parking, drives hide + CPU-park on inactive-mode leaves (`B_SHOWINTCP`/`B_SHOWINMIXER`/`B_MAINSEND`/`I_FXEN`, with per-FX offline deferred to `view_fx_park`), restores from snapshot. Owns the one discriminator (`target != active`) that separates a real switch from a reapply, and with it both the playback gate (`transportBlocksModeSwitch`) and the solo cache/clear/restore seams. **Never touches master or `B_MUTE`.**
-- `view_fx_park` — the per-FX offline surface: the `TrackFX_GetFXGUID` identity read snapshot/park/restore share, the deferred intent queue that keeps `TrackFX_SetOffline` off the switch's synchronous path (at most one intent per track GUID, latest wins, an intent landing on its own pending inverse cancels it), and the idle-tick drain `main.cpp`'s `OnTimer` calls. **The drain owns no model state.** A snapshot is dropped where the restore is PLANNED — the flags are back at their captured values from that moment, and a model that still described the track as parked would let a persist or a reapply inside the drain window replan a restore over whatever the user changed since. What the deferral costs instead is that the live FX chain stops being a trustworthy snapshot source while an intent is pending: a park that CANCELS a pending restore takes the pre-park FX states from that restore's ops (`preParkFxFromCancelledRestore`), because the chain still reads the parked values and the cancel means no drain will ever fix them.
+- `view_fx_park` — the per-FX offline surface: the `TrackFX_GetFXGUID` identity read snapshot/park/restore share, the deferred intent queue that keeps `TrackFX_SetOffline` off the switch's synchronous path (at most one intent per track GUID, latest wins, an intent landing on its own pending inverse cancels it — which is what makes a rapid A→B→A flip cost zero plugin work), and the two drains `main.cpp`'s `OnTimer` calls: `drainDeferredFxRestores` (whole, also forced by every persist path) and `tickDeferredFxParks` (one FX per tick, after a coalescing delay). A park that has already written one FX can no longer be cancelled outright in either direction — the live chain then matches neither endpoint, so the intent carries a `partial` flag and its inverse SUPERSEDES it instead. **The drains own no model state.** A snapshot is dropped where the restore is PLANNED — the flags are back at their captured values from that moment, and a model that still described the track as parked would let a persist or a reapply inside the drain window replan a restore over whatever the user changed since. What the deferral costs instead is that the live FX chain stops being a trustworthy snapshot source while an intent is pending: a park that CANCELS a pending restore takes the pre-park FX states from that restore's ops (`preParkFxFromCancelledRestore`), because the chain still reads the parked values and the cancel means no drain will ever fix them.
 - `view_solo` — the `I_SOLO` read/write pair behind the per-mode solo surface, plus `clearTrackSolos`/`restoreTrackSolos`, the outgoing-clear and incoming-replay entry points `view` drives them through. Holds no policy: what to cache, clear, or replay is `core/view/solo_cache`.
 
 ## Gotchas