ExecuteScript dispatch dies silently — no Activity node is ever created, and no failure mode in the chain is observable by the caller #841

Summary

The MCP ExecuteScript tool returns status: Dispatched, but the documented first step of every script run — "Creates a fresh Activity MeshNode for this run" (ScriptExecution.md) — never happens: the Activity node at the returned activityPath is never created, no ActivityLog appears anywhere, and the pod emits nothing at Warning or above. Reproduced 100% on a distributed local deployment, across a pod restart, with a minimal freshly created Code node.

How to reproduce (local dev portal, two-deployment topology, 2026-08-05/06)

1. Create a minimal Code node: content: { language: "csharp", isExecutable: true, code: "Log.LogInformation(\"ping\");" }.
2. Call MCP ExecuteScript on it → response { status: "Dispatched", activityPath: "{user}/_Activity/{id}", … }.
3. Poll get @{activityPath} → Not found, indefinitely. No new nodeType:Activity node appears anywhere in the mesh.
4. Restart the serving pod, repeat → identical.

Ruled out: a logged crash (pod stdout at Warning+ clean for the submission window), a transient kernel wedge (fresh pod), a malformed script (minimal ping; a realistic script fails identically).

The silent-failure chain (code map)

• MeshOperations.ExecuteScript (src/MeshWeaver.AI/MeshOperations.cs:3740-3742) posts ExecuteScriptRequest fire-and-forget to Address(codeNodePath). Dispatched means only "hub.Post did not throw". The ack (ExecuteScriptResponse) is deliberately not awaited — the code comment (:3718-3723) states routing it back to a hosted MCP session hub is fragile.
• The handler lives on the Code node's per-node hub (CodeNodeType.cs:64, HandleExecuteScript). If that hub never activates on the serving silo, the post is dropped with no diagnostic.
• If it does activate, HandleExecuteScript reads its own node via GetDataRequest with a strict timeout; the timeout path posts a failure ExecuteScriptResponse — which nobody observes (see above).
• All Information-level breadcrumbs in this chain (e.g. ExecuteScript called with path= at MeshOperations.cs:3703) are suppressed by the deployment's logging defaults (Memex.Portal.Distributed/appsettings.json: Default/MeshWeaver = Warning), so none of these cases leaves any trace in stdout.

What this issue asks for

1. The root cause of the drop on this topology (next diagnostic step per DebuggingMessageFlow.md: enable the messaging trace categories in the affected deployment and locate where the ExecuteScriptRequest delivery terminates).
2. Making dispatch failure observable: a dispatch whose Activity node does not materialize should surface as an error at Warning+ somewhere — currently the ScriptExecution.md step-1 contract can fail with zero trace, and the caller cannot distinguish "pending" from "dropped".

Not asked for: raising default log levels as the fix — the defect is the silent drop, not the logging configuration.