Remote update_artifact clears a live artifact's connector grants, with no UI path to restore them

### What happened?

A Cowork live artifact's calls to `window.cowork.callMcpTool(name, args)` failed for every connector, on every call, with the error shown in the "Error messages or logs" field below, even though the artifact's `cowork-artifact-meta` block correctly declared `mcpTools` and `mcpServerNames`.

This issue originally centered on a file-size hypothesis (the affected artifact was ~840 KB). That hypothesis has since been directly tested and refuted: a small (~4 KB) test artifact with the identical mcpTools/mcpServerNames declaration worked correctly on every call.

The confirmed root cause: calling the update_artifact tool from a cloud-hosted/remote session (bridged to a connected desktop, rather than running directly on the machine) clears the target artifact's connector grants, and that tool has no parameter to set them again. We found no way in the Claude Desktop UI to re-grant an artifact's connectors after this happens. The only working fix was to run a session directly on the local machine and republish the artifact through the native update_artifact tool there, passing the connector grant list as an explicit parameter. Simply having correct mcpTools/mcpServerNames values written in the artifact's own HTML was not enough; the platform's actual grant and the HTML's declared grant can silently diverge.

### What did you expect to happen?

One of the following:

Punkt 1: A remote update_artifact call should not clear an existing artifact's connector grants as a side effect of an unrelated content update.

Punkt 2: If clearing grants on remote update is intentional, the Desktop UI should provide a visible way to re-grant an artifact's connectors afterward.

Punkt 3: The remote/bridged update_artifact tool should accept the same explicit connector-grant parameter the local/native tool does, so a remote session can restore what it clears.

None of these currently exist, so any artifact updated from a cloud session can end up permanently broken until someone happens to know to republish it from a local session with explicit grants. This is hard to diagnose because the artifact's own cowork-artifact-meta block can still show the correct mcpTools/mcpServerNames text while the platform's actual grant is empty.

### Steps to reproduce

Step 1: Create a live artifact from a local session with mcpTools/mcpServerNames declared, and confirm window.cowork.callMcpTool calls succeed.

Step 2: From a cloud-hosted session bridged to the same desktop (not running directly on the machine), call update_artifact on that same artifact with any content change.

Step 3: Reopen the artifact and trigger a window.cowork.callMcpTool call. It fails with "not in this artifact's mcp_tools allowlist," even though the HTML's own cowork-artifact-meta block still declares the tools correctly.

Step 4: Look in the Claude Desktop UI for a way to re-grant the artifact's connectors. We did not find one.

Step 5: The only fix we found: run a session directly on the local machine and call the native update_artifact tool again, passing the connector grant list explicitly as a parameter.

### Area

Tool Discovery / Invocation

### MCP Server (if applicable)

Box, Gmail, Slack, and a Metricool community connector. Reproduced identically on all four, so this is not connector-specific.

### Error messages or logs

Tool "mcp____" is not in this artifact's mcp_tools allowlist.

### Additional context

Environment: Claude Desktop 1.25927.0 (Electron 42.7.0, Node 24.18.0), macOS arm64.

This issue was originally filed around a file-size hypothesis (~840 KB artifact). That hypothesis is refuted: a small test artifact with the same connector declaration worked fine. The description above has been rewritten to reflect the confirmed cause. We are leaving this open because the three points under "What did you expect to happen?" describe a real gap: there is currently no documented or discoverable way to recover an artifact's connector access once a remote update clears it, other than finding a way to run a session directly on the local machine.