docs(scripteditor): ctx-receiver scoping + SetVirtualTag single-tag-drop note

docs/ScriptEditor.md

@@ -217,11 +217,21 @@ are bounded to 200 entries to keep the completion list responsive on large fleet
 `TryGetTagPathLiteral` identifies the tag-path context by climbing from the
 syntax token under the caret to: `LiteralExpressionSyntax` → `ArgumentSyntax`
 (first argument only) → `ArgumentListSyntax` → `InvocationExpressionSyntax` →
-`MemberAccessExpressionSyntax`. The method name check is
-`method is "GetTag" or "SetVirtualTag"` — it matches by method name only, not
-by receiver type, so `anything.GetTag("…")` would also trigger tag-path
-completion. This is harmless in the sandbox (no other `GetTag` methods exist in
-the allowed reference set) and keeps the detection simple.
+`MemberAccessExpressionSyntax`. It then requires (a) the method name is
+`GetTag` or `SetVirtualTag`, and (b) the **receiver is the identifier `ctx`** —
+a purely syntactic check that deliberately mirrors the runtime dependency
+harvest (`EquipmentScriptPaths.GetTagRefRegex` is `ctx`-anchored), so the editor
+offers tag-path completion/hover for exactly what `Phase7Composer` harvests at
+deploy time. An unrelated `anything.GetTag("…")` no longer triggers it.
+
+**`SetVirtualTag` is a no-op in production.** The live single-tag evaluator
+(`RoslynVirtualTagEvaluator`) drops cross-tag `ctx.SetVirtualTag(...)` writes
+(logged); the cascade `VirtualTagEngine` that honours them is dormant (not wired
+into the host). So hover on a `ctx.SetVirtualTag("…")` path literal appends a
+note that the write is dropped in single-tag mode and will not take effect at
+runtime — the path completions still help author the literal, but the author is
+not misled into relying on a no-op. Making `SetVirtualTag` functional would
+require wiring the cascade engine into the host (out of scope).
 
 ---