fix(rovodev): nest per-tool permissions under toolPermissions.tools and translate MCP transport

[dyoshikawa]

Two adapter bugs where rulesync wrote a key Rovo Dev does not read, plus the ownership and fail-closed fixes that fell out of reviewing them.

1. Per-tool permissions were written one level too shallow

Rovo Dev documents per-tool levels under toolPermissions.tools.<tool>. Rulesync wrote them directly under toolPermissions.<tool>, where Rovo Dev ignores them — so generated permissions never applied, and importing a real user config round-tripped to nothing. Confirmed against the live use tools page, which shows:

toolPermissions:
  tools:
    create_file: ask
    open_files: allow

Generate now writes the nested block, and import reads it — falling back to the legacy flat shape only for a key the nested block says nothing about, so a config.yml an earlier rulesync produced still imports.

Not implemented from the issue's gap 1: toolPermissions.default. The issue's YAML block shows it, but the live docs page does not, so the claim could not be confirmed from a primary source.

2. MCP servers carried the canonical type instead of transport

Rovo Dev documents the per-server transport key as transport (stdio | http | sse), with no type alias. RovodevMcp.fromRulesyncMcp wrote getMcpServers() verbatim, so a canonical "type": "http" — the spelling this repo's own .rulesync/mcp.json uses — reached the file under a key Rovo Dev does not read.

Translated in both directions (local → stdio, streamable-http → http, sse → sse), matching the kilo / roo / goose / amp / codexcli adapters. Two entries are skipped with a warning rather than written as a guess: a ws server (no Rovo Dev equivalent — same as the Kimi Code adapter) and a disabled one, since Rovo Dev turns servers off through mcp.disabledMcpServers in config.yml and mcp.json has no flag for it. On import, a transport value outside Rovo Dev's vocabulary is dropped rather than carried into the canonical config, whose transport field is a strict enum — passing one through would make .rulesync/mcp.json fail to parse for every target.

3. Ownership: a revoked rule now actually goes away

Fixing (1) surfaced a worse problem than the wrong depth. bash, allowedExternalPaths, and the eight per-tool keys were merged into whatever was already in config.yml, so deleting a rule from .rulesync/permissions.* left the old value live — and the stale flat copies were then resurrected by the import fallback and propagated to every other tool. Those keys are rulesync-owned now: dropped before the current set is written, with the keys rulesync has no category for (createTechnicalPlan, the Jira/Confluence tools) left untouched.

Two guards around that:

• A generate that produces nothing this adapter can express leaves the block alone rather than emptying it — there would be no rule of ours to replace the user's levels with.
• Removing an owned key logs a warning, because allowedExternalPaths is also written from inside a session by /directories.

4. Collisions resolve fail-closed

Both directions had a path where the looser of two levels won:

• Import. A category maps onto four tool keys, and Rovo Dev rewrites a single key when the user answers "always allow" to one prompt. Last-write-wins meant grep: allow next to three denies imported as a blanket read: allow. They fold onto the strictest level now, matching the augmentcode and opencode adapters.
• Generate. edit and write drive the same mutation tools, so a conflicting catch-all cannot be represented. Resolving to edit wrote an allow when the author had also said write: deny; the stricter level is kept instead, and the warning names it.

Left open on the issue

• .rovodev/.review-agent.md (checks) — needs a new RovodevCheck adapter; a feature addition rather than a drift fix.
• mcp.disabledMcpServers — honouring canonical disabled means making the MCP feature a second writer of the config.yml the permissions feature already owns, with sub-key seeding so mcpConfigPath / allowedMcpServers survive. Worth doing, but its own change.
• hooks — still blocked upstream: /hooks and eventHooks are referenced but the schema has never been published.

Follow-up worth filing

strictestAction here is the fourth implementation of deny > ask > allow in src/features/permissions/ (grokcli, opencode, amp). A shared helper would be the right home for it.

Tests

52 unit assertions across the two adapters, including the legacy-flat import, the nested-wins direction where the nested value is the looser one (so a regression is visible), the strictest fold, ownership deletion vs. preservation of unmapped keys, both conflict directions, the five transport translations, and the skip cases. The e2e permissions case moved to the nested depth.

pnpm cicheck and the permissions/MCP e2e suites pass locally.

Refs #2422

[dyoshikawa]

@dyoshikawa Thank you!