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

agent/src/registry/loader.py:217 から始めて skip-worktree が適用される箇所を追跡し、次に runner.py:525-553 を読んで既存の in-process での mcp_servers 処理を確認してください。選択した変更を受け入れ条件に照らして検証してください。正当な .mcp.json の編集が黙って破棄されてはならず、抑制を行う場合はそのすべてを trajectory で説明する必要があります。

索引モデルが issue の本文から書いたものです。