An ACP client cannot attach to the agent an interactive `goose run` is driving

**What problem would this solve?**

I run goose interactively in a terminal and I also want a program — an editor, a supervisor, a
control plane — to send prompts to *that same* session. Today that's a choice: `goose serve`
gives me ACP but no terminal, `goose run` gives me the terminal and nothing can reach it.

Pointing a separate `goose serve` at the run's session id isn't a workaround. Sessions live in
one store, so the id resolves and the history replays — but that process builds its own `Agent`.
Two agents then own one session: the terminal never sees the other's turns, and both write back
to the same conversation.

Who it affects: anyone embedding goose behind an operator's terminal — supervisor setups where a
human watches a session a program is also driving, editor-attaches-to-running-CLI, and
integration tests that need a real interactive session rather than a headless stand-in.

**What would a good outcome look like?**

An interactive `goose run` can optionally accept ACP connections, and a client that attaches gets
*the running agent*, not a copy: `session/load` resolves to the agent the TUI is driving, and
prompts execute against its live state. Opt-in and off by default.

**Possible approaches**

Two steps, and the first stands on its own (embedding, tests): let a host hand its
already-constructed agent to the ACP server, which today always builds its own; then opt-in
wiring on the run side so an interactive session can serve ACP against it, loopback-bound and
reusing the existing transport and secret-key auth rather than adding another.

Design questions I'd rather settle here than in a patch:

- Opt in via env var (consistent with `GOOSE_SERVER__SECRET_KEY`, easy for a container to set) or
a `goose run` flag?
- Should the run-side server start the scheduler? I'd say no — the run owns its lifecycle — but
it's worth deciding explicitly.
- Lifetime: agents live in an LRU keyed by session id (`GOOSE_MAX_ACTIVE_AGENTS`, default 100).
A host-owned agent isn't a cache entry — evict it and the next attach silently rebuilds a
separate agent that, since #7615, looks healthy while being exactly the two-agents-one-session
problem above. I don't think such an agent should be evictable while its owner is alive.
- Discovery: `session/list` already returns CLI-created sessions, so this may need nothing —
worth confirming rather than assuming.

Non-goals: no change to `goose serve`, to how turns are produced, or to any provider; not
concurrent turns — the agent still handles one at a time, this is about who can ask. Rendering
remotely-initiated turns in the terminal is a separate problem, filed separately.

**How I'd verify it**

- Off: existing behaviour untouched, since the new path is never entered.
- On: attach a client, `session/load` the running session, send a prompt — the turn executes
against the *running* agent, observable as shared state (it answers from the conversation just
typed in the terminal, and lands in that session rather than a new one).
- A unit test that the attached client resolves to the same agent instance, not an equal-looking
one. That distinction is the whole point and regresses silently.

**Additional context**

#4387 established agent-per-session and `AgentManager`, and #7615 made an evicted agent
restorable — both treat the manager as where session-to-agent ownership is decided, which is
where this asks for one more option. Discussion #7697 goes further, with the interactive CLI
becoming an ACP client of an in-process agent: same destination as this issue, reached wholesale
rather than at one seam. If that's still the plan I'd rather this be a step toward it than a
detour around it.

I have an implementation of both steps running in a fork on my own deployment — days on a single
agent, not a long soak. Enough to say the shape works and where the sharp edges are. Happy to
take the implementation once this reaches Ready.

- [x] I have verified this does not duplicate an existing feature request