ACP: disabled extensions are invisible to external harness sessions — no on-demand activation path outside the Goose agent loop

## Summary

For sessions running external agent harnesses over ACP (`claude-acp`, `codex-acp`), goosed converts the **enabled** extensions from its config into the MCP server list handed to the harness at startup (`extension_configs_to_mcp_servers` in `crates/goose/src/acp/provider.rs`, used by `providers/claude_acp.rs` and `providers/codex_acp.rs`).

The extension manager platform extension (`agents/platform_extensions/ext_manager.rs`) solves context cost for **disabled** extensions — the agent can discover and enable them mid-session — but it lives inside Goose's own agent loop. External harnesses never see it.

This leaves clients that install MCP extensions with a hard fork:

| Install as | Goose sessions | External harness sessions (claude-acp / codex-acp) |
|---|---|---|
| **Enabled** | Full tool schemas in context at session start | Works — full tool schemas in context |
| **Disabled** | Zero context cost; agent can enable on demand via extension manager | **Silently absent** — no discovery, no activation path |

Either the user pays full context cost for every installed extension in every session in every harness, or the extension exists only in Goose sessions and the absence in external harnesses is invisible to the user.

## Why this matters

Client apps (Goose Desktop, ACP clients embedding goosed) increasingly present "install this MCP once, use it in any harness" experiences. The current design forces those clients to install extensions enabled to keep that promise, negating the extension manager's context savings for exactly the extensions users touch most.

## What exists today (partial mitigations)

- `session/new` `_meta.enabledExtensions` lets a client scope which extensions a specific session carries — useful, but it pushes the routing decision to the client at session creation, before anyone knows what the conversation needs.
- The unstable ACP MCP-over-ACP transport (`mcp/connect`) hints at a channel where the client could mediate, but there's no discovery/activation semantic on top of it.

## Possible directions (not prescriptive)

1. **On-demand extension activation for external harnesses** — e.g. goosed exposes a lightweight meta-MCP to the harness (one `search`/`activate` tool pair) that proxies the extension manager, so a Claude Code or Codex session can pull in a disabled extension the way a Goose session can.
2. **Deferred tool-schema loading in the projection** — hand external harnesses server stubs whose tools materialize on first use.
3. **Documenting enabled-everywhere as the intended model** for external harnesses, so clients can design around it deliberately.

## Environment

Observed at `2694fff7e` (main) reading source; behavior confirmed for `claude-acp` and `codex-acp` providers.

---
🤖 Filed by an AI agent on behalf of morganm.