feat(commands): register generated Goose recipes as slash commands

[dyoshikawa]

Goose recipes do not auto-register: /name only resolves once the recipe is listed under slash_commands in the user config, so a generated recipe was uninvocable without hand-editing ~/.config/goose/config.yaml.

Verified upstream before implementing: the entries are SlashCommandMapping { command, recipe_path } (https://github.com/block/goose/blob/main/crates/goose/src/slash_commands/recipe_slash_command.rs), and recipe_path goes through tilde/relative expansion via convert_path_with_tilde_expansion in crates/goose/src/recipe/read_recipe_file_content.rs — so the registration is written as ~/.config/goose/recipes/<name>.yaml rather than a machine-specific absolute path.

Implementation:

• GooseCommand.getAuxiliaryFiles emits the user config.yaml in global mode only (upstream has no project-level registration surface; project recipes still need goose run --recipe).
• The gateway declaration for .config/goose/config.yaml gains commands: replace-owned-keys over slash_commands, alongside the existing mcp ownership of extensions.
• Ownership is narrow, per the Hermes lesson: only entries whose recipe_path resolves to a direct child of the managed recipes directory are rulesync's. User entries elsewhere — and sub-recipes under recipes/subagents/ — are carried over untouched, and an unresolvable path is preserved rather than claimed.
• Removing the last generated command retracts the registrations and drops the key; the config file is never created when there is nothing to register, and is never a deletion candidate.

Tests cover registration, project-scope no-op, preservation, stale-entry replacement, retraction and the no-op case; the shared-file-derive snapshot now pins commands+mcp as the writers of that file. e2e-commands passes locally.

Gap 1 (the Goose review-checks adapter) remains blocked on the .agents/checks path-collision ownership call.

Part of #2404

🤖 Generated with Claude Code