registry: skip-worktree on .mcp.json silently discards the agent's own legitimate edits (#665 B4 #3)

**Source:** BLOCKING #3 (new) from @scottschreckengaust's review of #665 — https://github.com/aws-samples/sample-autonomous-cloud-coding-agents/pull/665#pullrequestreview-4915535549 (`agent/src/registry/loader.py:217`)
**Parent:** #246 · **Sibling blockers:** #758 (symlink), and the fail-open guard issue

## Problem
`git update-index --skip-worktree .mcp.json` makes git ignore **all** worktree changes to that path, not just the loader's write. Once a registry `mcp_server` asset is pinned, any task whose actual job touches `.mcp.json` — plausible here, where `channel_mcp.py` writes it and `strip_linear_mcp_servers` edits it — loses its work. Reproduced with the real loader:

```
# task: "register our new internal MCP server in .mcp.json"
agent: git add .mcp.json -> exit 1
"matched paths that exist outside of your sparse-checkout definition, so will not be updated"
agent: git commit -am … -> exit 1 ("nothing to commit, working tree clean")
git status --porcelain -> '' (edit is invisible)
```

Two harms: (a) **silent loss** of agent output while the PR reports success — the exact failure class `ensure_committed` exists to prevent; (b) git blames **sparse-checkout**, which is not what happened, so the model burns turns chasing a nonexistent sparse config and may trip `stuck_guard`.

This is a **data-loss / correctness** bug (not security), and it is the structural cost of masking a confidentiality problem with a VCS flag.

## Fix
Disappears entirely under Scott's recommended approach — pass the resolved runtime through the SDK's in-process `mcp_servers` option (`runner.py:525-553` already does this for the clarification server), so `.mcp.json` is never written in the repo. That closes #758 + the fail-open issue + this one together, with less machinery than the skip-worktree guard.

If the flag is kept as an interim: at minimum emit a `TASK`-level line naming `.mcp.json` as platform-managed and uncommittable for the task, so the trajectory records the cause instead of a misleading sparse-checkout error.

## Acceptance
- A task that legitimately edits `.mcp.json` is not silently dropped, and any suppression is explained in the trajectory

Start at agent/src/registry/loader.py:217 to trace where skip-worktree is applied, then read runner.py:525-553 for the existing in-process mcp_servers handling. Verify the chosen change against the acceptance case: legitimate .mcp.json edits must not be silently dropped, and any suppression must be explained in the trajectory.

Written by the indexing model from the issue text.