fix: complete prompts on newly forked sessions

[aiguy110]

Summary

• reactivate the Codex app-server subscription before the first direct prompt on a newly forked ACP session
• preserve the intentional post-fork thread/unsubscribe, so another ACP process can still load the persisted fork
• add a bounded event-driven regression test that requires both streamed fork output and a resolved prompt response

ACP lifecycle

The ACP session/fork RFD motivates the method with a client flow that forks, issues additional messages, and closes the fork. It also specifies a response shaped like session/new. The draft schema describes the returned ID as the newly created forked session and does not require an intervening session/load or session/resume.

Therefore a successful session/fork response must produce a session that accepts session/prompt directly. Explicit session/load remains valid for a persisted/inactive fork, but it is not a required activation step after a successful fork on the same ACP connection.

Observed behavior

With codex-acp 1.8.0 and Codex 0.152.1:

1. session/fork(parentSessionId, cwd, mcpServers) returned a fork session ID.
2. session/prompt(forkSessionId, prompt) was accepted.
3. Codex completed and persisted the answer internally.
4. The ACP client received no answer session/update notifications.
5. The session/prompt request remained pending indefinitely.

A real-Codex reproduction using the repository /run-codex harness timed out the direct sequence after 30 seconds with zero updates. The control sequence fork -> load -> prompt completed in 2.7 seconds.

Client impact: Tandem

This does more than lose streamed output. Tandem records the aside as started and changes the parent agent to working, but receives neither the answer updates nor the prompt response. The UI leaves the aside card permanently at “Asking in existing context…”, while the completed answer exists only in Codex internal history.

Tandem serializes ordinary prompts and isolated asides through one queue. The unresolved aside therefore blocks every later prompt behind it, and its cleanup path never reaches session/close. The parent conversation remains correctly unmodified; the failure is delivery and lifecycle completion, not isolation.

Root cause

The fork implementation intentionally calls app-server thread/unsubscribe after thread/fork to release the writer for clients such as AIR that may load the fork through another ACP process. codex-acp nevertheless installs the returned fork in its local ACP session map as if it were immediately promptable.

Before this change, a direct prompt started a turn on that unsubscribed thread. Codex executed it, but app-server delivered no thread notifications to this connection. CodexAppServerClient.runTurn consequently never observed turn/completed, so codex-acp emitted no answer updates and never resolved the ACP prompt.

This PR keeps the unsubscribe behavior. The ACP session state records that a new fork needs resubscription, and the first direct prompt resumes the thread before registering prompt handlers and starting the turn. An explicit session/load creates an already-subscribed session state and does not take the lazy-resume path.

Regression test

The new test:

• creates a fork and immediately prompts its returned session ID;
• simulates app-server message and completion notifications;
• requires the ACP agent_message_chunk for the fork;
• requires the prompt response to resolve with end_turn;
• uses a one-second timeout so the original indefinite wait fails deterministically.

Verification

• npm run typecheck
• npm test — 487 passed, 26 skipped
• real Codex: fork -> prompt — completed in 3.3 seconds after the fix
• real Codex: fork -> load -> prompt — completed in 3.8 seconds after the fix