[FEATURE] Add Goose as a consumer target for APM packages

Is your feature request related to a problem? Please describe.
Goose is a commonly used harness. A user who wants to consume an APM package in Goose currently has to wire some primitives by hand:

• MCP servers (the main gap): Goose calls MCP servers "extensions" and stores them only in a single home config, ~/.config/goose/config.yaml, in YAML, using a Goose-native per-server schema (type: stdio / cmd / args / envs / timeout; remote servers use type: streamable_http + uri). No existing APM adapter writes this format, so mcp: dependencies from an APM package must be transcribed into config.yaml manually.
• Agents: there is no goose-specific destination for the APM agents primitive today.
• Instructions and skills are largely covered already: Goose reads AGENTS.md natively (context files are .goosehints and AGENTS.md by default), and it reads the cross-tool .agents/skills/ standard, which the existing agent-skills target deploys. A goose target should reuse these rather than duplicate them.

Describe the solution you'd like
Add goose as a consumer target behind the existing experimental-flag lifecycle (apm experimental enable goose), matching how other frontier targets ship (hermes, openclaw, copilot-app): never auto-detected, excluded from --target all, inert until enabled.

Proposed surface mapping, with open design questions flagged:

Agents mapping — open design question for maintainers:

• Option A: Goose's own agent/subagent surface (agents invocable through delegation). This is the closest primitive-to-primitive match for an always-available, described agent.
• Option B: Goose recipes at .goose/recipes/<name>.yaml, run via goose run --recipe. Recipes are parameterized, prompt-driven workflows; they resemble workflows/skills more than agents, so this fit is debatable and worth maintainer direction.

Success criteria:

• apm install --target goose --global writes mcp: dependencies into the extensions: block without clobbering an existing config.yaml.
• Instruction and skill primitives reach Goose through the surfaces it already reads (AGENTS.md, .agents/skills/), without redundant copies.
• The target stays inert and invisible until the experimental flag is enabled.

Describe alternatives you've considered

• Status quo: hand-transcribing MCP servers into ~/.config/goose/config.yaml whenever an APM package declares them.
• Relying only on the existing agent-skills target plus AGENTS.md, leaving MCP — the one truly Goose-specific surface — unmanaged.
• Mapping APM agents to recipes (as the draft implementation in #1833 does): recipes are headless-runnable and parameterizable, but as workflows they may be the wrong analogue for the agents primitive; maintainer guidance on the right surface is requested before settling this.
• Not adding a target at all, on the theory that the cross-tool standards partially cover Goose; this leaves the YAML extensions: config as a permanent manual step.

Additional context

• An implementation exists in #1833 ("feat(goose): add experimental Goose (Block) harness"), which was closed for inactivity without a backing issue; this issue provides that backing. It chose Option B (recipes) and additionally emitted a .goosehints stub — both points worth revisiting per the open questions above. I'm happy to help with design, implementation, and testing, e.g. rebasing/reopening #1833 against this issue and adjusting the mapping.
• That PR also fixes a pre-existing crash where apm install --target <experimental-target> aborted whenever the package declared an mcp: dependency, and adds Goose to the MCP runtime-discovery list.
• References: Goose docs at https://goose-docs.ai; experimental-flag lifecycle in CONTRIBUTING.md.

Start with CONTRIBUTING.md's experimental-feature-flag lifecycle and inspect the closed implementation in #1833. Review Goose's configuration documentation, then exercise apm install --target goose --global with existing MCP settings. Done means the maintainer-approved agent mapping works, existing configuration is preserved safely, shared instruction and skill surfaces are reused, and the target remains inert until enabled.