fix(acp): re-establish a forked session before prompting on it

`session/fork` returns a session id that neither adapter leaves usable,
in two different silent ways.

claude-agent-acp 0.73.0's `unstable_forkSession` hands back the SDK's
`{ sessionId }` verbatim and never inserts it into its own session map,
so the first `session/prompt` on the fork throws "Session not found". It
also returns no modes and no config options at all.

codex-acp 1.8.0's `SessionFork` unsubscribes the freshly forked thread to
release its writer lock. A prompt then runs to completion inside codex —
the rollout file grows — but the core streams no turn notifications to an
unsubscribed thread, so `runTurn` awaits a completion event that never
arrives: the turn hangs and nothing reaches the transcript until the
conversation is reopened.

Send `session/resume` for the forked id before attaching. That registers
the session on claude (`createSession` keeps `resume` as the id) and
re-subscribes the thread on codex, and its response also supplies the
modes and config options the claude fork response omits. An agent that
forks without advertising resume, or whose resume fails, still attaches
the fork response exactly as before.