Split unidentified from missing FX in Design View drop report, fix message + console pop

Distinguish no-GUID-at-capture from identity-no-longer-live; rewrite the drop
message to state the real recovery step; mark FX-GUID stability [verify — DAW];
guard mismatched fx/fxOffline lengths; the report never force-opens now.

src/shell/view/CLAUDE.md

@@ -103,3 +103,12 @@ applies the resulting lane state to live tracks.
   under whatever mode id is active at that point, not the one the user undid back
   to. Pre-existing: `snapshots_` already carries this same model-vs-undo split;
   the solo cache inherits it rather than introducing it. Not fixed here.
+- `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.cpp`) and SWS issue #802 is a
+  known reason it might not hold: `SNM_MoveOrRemoveTrackFX` reportedly leaves
+  the FXID lines behind on reorder rather than moving them with the plugin. If
+  confirmed, an SWS-driven reorder of a parked track's chain — not a native
+  drag-reorder — can produce wrong-plugin restores or mass drops through
+  `resolveFxRestore`. Do not design around this pre-emptively; if native
+  reorder is clean (the likely case), only the SWS path degrades.

src/shell/view/view.cpp

@@ -129,7 +129,18 @@ MediaTrack* resolve(const std::vector<std::pair<std::string, MediaTrack*>>& hand
 
 // The FX's own durable identity, braced exactly like the track GUID keys. Empty
 // when REAPER reports none — an FX we cannot name is one we cannot restore, and
-// fx_offline treats it that way rather than guessing at its slot.
+// fx_offline treats it that way rather than guessing at its slot. Lifetime is
+// settled: the string copy is taken immediately and the GUID* is never held
+// past this call (reaper_plugin_functions.h:7348 documents no null contract for
+// TrackFX_GetFXGUID; treating null as "no identity" is the safe read).
+//
+// [verify — DAW] STABILITY across a chain mutation is not settled the same way:
+// confirm the GUID for one FX instance survives a native drag-reorder, an SWS
+// move (SNM_MoveOrRemoveTrackFX — SWS issue #802 reports the FXID lines do not
+// follow the plugin after that call, i.e. wrong-plugin restores or mass drops
+// through fx_offline on that path specifically), a save/reload round trip, and
+// two live instances of one plugin type staying distinguishable. See
+// src/shell/view/CLAUDE.md's Gotchas for the SWS-path risk this leaves open.
 std::string fxGuidString(MediaTrack* tr, int fx) {
     GUID* g = TrackFX_GetFXGUID(tr, fx);
     if (!g) return {};
@@ -491,9 +502,16 @@ bool applyMode(ViewModeModel& model, const std::string& targetModeId, ReaProject
 
     // Captured FX state that could not be applied is REPORTED. Silence here would
     // read to the user as "restore worked" while an FX sat at whatever state the
-    // park left it in.
+    // park left it in. Sent with the "!SHOW:" prefix (reaper_plugin_functions.h:6536)
+    // so it never force-opens the console window: applyMode's reapply path also
+    // runs unattended on project load (see the reconcile comment above), and this
+    // one call site can't tell that case apart from an interactive toggle/tag-edit
+    // reapply — both call in with target == active — so splitting loud-on-toggle
+    // from quiet-on-load would need a flag threaded from every caller, several of
+    // which are outside this change. Quiet-always is the safe default: the message
+    // still lands in the console for whoever opens it, on every path.
     const std::string fxDropMsg = describeFxRestoreDrops(fxDrops, fxDropTracks);
-    if (!fxDropMsg.empty()) ShowConsoleMsg(fxDropMsg.c_str());
+    if (!fxDropMsg.empty()) ShowConsoleMsg(("!SHOW:" + fxDropMsg).c_str());
 
     // MANAGED LANES: drive C_LANEPLAYS so the active mode's lane plays+shows
     // and every other managed lane is silenced+hidden. Empty for a D1-only