Fix drag-drop review findings: unify teardown, gate FX-add on outside-panel, trim comments

tests/test_instrument_drop.cpp

@@ -234,18 +234,10 @@ static void testEmbedStripIsNotHotspot() {
     CHECK(!infoNamesFxHotspot("mcp.fxembed extra"));
 }
 
-// --- Drop surface parity: container vs FX button ------------------------------
-//
-// The container-drop regression (instance loads, capture does not): the two surfaces must be
-// one code path carrying one payload. buildInstrumentDropPreset takes only sampleId, so the
-// payload side of that claim is already proven once by testPresetRoundTripsThroughInstrumentReader
-// and every "fx_"/"tcp.fx"/"mcp.fx" surface classifying as a hotspot is proven by
-// testTcpMcpFxFamilyIsHotspot / testFxWindowStillHotspot. A loop that reruns both against a
-// fixed sampleId per surface string can't distinguish the surfaces (the loop body is identical
-// every iteration) — it isn't a stronger test than those two, so there is no separate test here.
-// The one thing that DOES vary by surface — the shell's TrackFX_AddByName `instantiate` value
-// picked for a container drop vs. a bare FX-button drop — lives in instrument_drop_win.cpp and
-// is untestable without a live DAW (GetThingFromPoint/TrackFX_AddByName have no pure model).
+// Do not reintroduce a per-surface "capture carries" loop test: buildInstrumentDropPreset takes
+// only sampleId (proven by testPresetRoundTripsThroughInstrumentReader), and per-surface hotspot
+// coverage already exists (testTcpMcpFxFamilyIsHotspot / testFxWindowStillHotspot) — a loop with
+// an identical body per surface string can't distinguish them.
 
 // --- All-or-nothing rollback --------------------------------------------------