[IJAI-1133]: fix(client): don't fail session/update for sessions the client never connected to

[forketyfork]

Issue

https://youtrack.jetbrains.com/issue/IJAI-1133

session/update (including session_info_update) notifications fail with acpFail("Session <id> not found") when the client hasn't called session/new / session/load / session/resume for that sessionId — unless another session happens to be mid-initialization at that exact moment.

This is too strict: sessions can live on the server and be created, updated, or deleted from another IDE window, the web, or another machine. An agent notifying this client about such a session (e.g. a status change for a session shown in a session list) is not a protocol violation, so the client shouldn't treat it as an error — and once it isn't an error, the client should be able to observe it (e.g. to keep a session/list-rendered list live without polling).

Solution

In Client.kt, the session-holder lookup used by getOrCreateSessionHolder was extracted into a new non-throwing findSessionHolder(sessionId): ClientSessionHolder?.

• The session/update notification handler now calls findSessionHolder and, when it returns null (session unknown and not currently being initialized), no longer fails.
• getOrCreateSessionHolder keeps its old throwing behavior on top of findSessionHolder, and is unchanged for every other call site (FsReadTextFile, TerminalCreate, ElicitationCreate, etc.) — those are genuine session-scoped requests from the agent and must still fail fast if they reference a session the client never established.
• Added GlobalSessionUpdateHandler, an optional Client constructor callback mirroring the existing GlobalElicitationHandler pattern. When an update arrives for a session with no registered holder, it's routed to this handler if one is set (e.g. to add a newly-appeared session to a locally displayed list); if none is set, the update is dropped with a debug log, same as before.
• Closed the gap where the initialization race swallowed such updates. findSessionHolder still speculatively creates a placeholder holder while initializingSessionsCount > 0, so an update for an unrelated server-side session arriving in that window gets buffered rather than routed to the handler. When the last initialization finishes and no session/new / session/load claimed that id, withInitializingSession's hanging-session cleanup now uses ClientSessionHolder.completeExceptionallyAndDrainQueue to drain the buffered notifications before closing the holder, and forwards each to globalSessionUpdateHandler — the id is unconnected after all, exactly as if no initialization had been in progress when its updates arrived. createSession's own failure path still uses the plain completeExceptionally: those buffered notifications belong to a session this client tried and failed to create, not to an unconnected one.

Client's constructor takes both globalElicitationHandler and globalSessionUpdateHandler as optional parameters defaulted to null. As with 1e717bb, which introduced globalElicitationHandler the same way, this shifts the published JVM constructor descriptors, so acp/api/acp.api is regenerated: the 3-arg constructor and its DefaultConstructorMarker synthetic replace the previous 2-arg pair.

Context

• Related but out of scope: IJAI-1134 — paginated session/list hook, follow-up PR [IJAI-1134] feat(agent,protocol): support suspend-based paginated session/list #123.

Covered by automated tests in acp/src/jvmTest: ClientSessionUpdateForUnconnectedSessionTest (unknown-session updates no longer fail), ClientGlobalSessionUpdateHandlerTest (delivery to the global handler), and ClientHangingSessionUpdateDeliveryTest (an update for an unrelated session fired while a session/new is in flight still reaches the handler).

[Rizzen]

Why two ctors instead of single ctor with two nullable optional args?

[forketyfork]

No good reason, removed.