fix(copilot): map edits/urls approvals, stop clobbering mcp.json inputs/sandbox, add the user-scope hooks file

[dyoshikawa]

Background

Addresses gaps 1-4 and 6 of #2401. Gaps 5 and 7 are deliberately left open, so this PR does not close the issue.

Gaps 1-2 — chat.tools.edits.autoApprove / chat.tools.urls.autoApprove

The adapter was hard-coded to a single category (bash → the terminal map). It now drives three flat dotted keys from three canonical categories, all sharing the same pattern-to-boolean shape and the same allow → true / deny → false / ask → omitted semantics:

canonical	VS Code setting
bash	chat.tools.terminal.autoApprove
edit	chat.tools.edits.autoApprove
webfetch	chat.tools.urls.autoApprove

read has no VS Code approval surface. write is deliberately not folded into the edits map alongside edit — doing so would make the two indistinguishable on import, the same lossiness the Antigravity adapter documents for its write_file collapse. VS Code's per-URL {approveRequest, approveResponse} object form has no canonical action, so it is skipped on import; since rulesync owns the key outright it is replaced when the canonical config carries any webfetch rule, which is the same ownership rule the terminal map already had.

The two new keys are registered in the .vscode/settings.json ownedKeys declaration — the shared-config gateway rejected the write until they were, which is the guard working as intended.

Gap 3 — .vscode/mcp.json no longer clobbers inputs / sandbox

fromRulesyncMcp never read the existing file: it built { servers } and wrote the whole document, so a hand-authored inputs or sandbox section was deleted on the next generate. VS Code recommends committing this file, so the loss was user-visible — once ${input:…} becomes unresolvable, the affected servers fail to start.

It now reads the file first and replaces only servers, preserving inputs, sandbox and any future top-level section (the ClaudecodeMcp pattern). An existing file that cannot be parsed aborts with an error rather than being overwritten, so a malformed file never silently loses its contents.

Gap 4 — user-scope hooks at ~/.copilot/hooks

CopilotHooks.getSettablePaths() ignored its global option, fromRulesyncHooks never read it, and the processor declared supportsGlobal: false, so a global run emitted no Copilot hooks at all. The VS Code hooks doc and the coding-agent hooks doc both document ~/.copilot/hooks as the user scope and state that every *.json in the folder is loaded. Global mode now writes ~/.copilot/hooks/copilot-ide-hooks.json — a distinct name, because the Copilot CLI's global hooks file already occupies copilot-hooks.json in that same folder.

Gap 6 — name frontmatter on *.instructions.md

Added to CopilotRuleFrontmatterSchema and to the copilot section of RulesyncRuleFrontmatter, carried through in both directions alongside excludeAgent.

Gaps 5 and 7 — left open

Gap 5 (preCompact / subagentStart): VS Code's side is now confirmed — the hooks doc lists exactly eight events including PreCompact and SubagentStart. What is still unconfirmed is the gating question the issue itself raised: .github/hooks/*.json is shared with the cloud coding agent, which does not document those two, and whether it ignores or rejects unknown event keys is not stated anywhere. Emitting keys that might break the cloud agent for everyone who enables the copilot target is not a call to make on inference.

Gap 7 (REVIEW.md): the issue notes this is an alternative location rather than a missing capability, since .github/copilot-instructions.md is still read by code review. Whether rulesync should own a review-only rules surface is a scope decision.

Verification

• Full pnpm cicheck green.
• e2e-hooks (75), e2e-mcp / e2e-permissions / e2e-rules (308) all pass; the global hooks e2e matrix gained a copilot cell.