fix(custom-model): wait for a freshly launched session to go idle before applying

Root cause of every 'Session is busy' apply failure reported from live
testing: a just-launched CLI reports itself 'busy' for its own startup
(boot spinner, workspace-trust check) well before runCustomModelEntry's
apply call could reach it, and the apply route's isBusy() guard correctly
cannot tell that apart from a real turn in progress — it exists precisely
to refuse restarting a session mid-turn, and a fresh boot looks exactly
like one from the outside. Confirmed live: replaying the identical apply
call by hand against the same session, once it had settled, succeeded
immediately.

Fixed by waiting on the session's own readiness signal before applying:
GET /api/sessions/:id/wait?until=idle&timeout=20000, one GET already built
for exactly this ('Agent wait primitives', CLAUDE.md) rather than inventing
a client-side poll loop. A timeout there is a normal 200 per that
endpoint's own contract, never an error, so a session still busy after 20s
just reaches the apply call anyway and gets the route's own honest error —
now visible, since the previous commit made error toasts sticky and
stopped discarding the real error text.

Tests: new case in custom-model-run-menu-ui.test.ts pins the ordering (the
wait call happens, and strictly before the apply call) and its exact query
string.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RqZeHrRS6DYcGcGX2p9EwG

test/custom-model-run-menu-ui.test.ts

@@ -340,6 +340,37 @@ describe('Custom Model Endpoint Profiles: applying a picked entry', () => {
     expect(calls[0].body).toEqual({ endpointId: 'llama-box', modelId: 'qwen3' });
   });
 
+  it('waits for the freshly launched session to go idle before applying, so its own boot activity is never mistaken for a busy turn', async () => {
+    // Measured live: a just-launched CLI reports 'busy' for its own startup
+    // (spinner, workspace-trust check) well before the apply call could
+    // otherwise reach it, and the apply route's isBusy() guard correctly
+    // refuses to restart a session mid-turn — which a fresh boot looks
+    // exactly like from the outside. This pins the fix: wait for idle FIRST.
+    const { app } = bootApp({});
+    app.activeSessionId = 'old-session';
+    app.run = async () => {
+      app.activeSessionId = 'new-session';
+    };
+    const calls: string[] = [];
+    app._apiJson = async (path: string) => {
+      calls.push(path);
+      if (path === '/api/model-endpoints') return [];
+      return null; // the wait call's return value is unused — a timeout is a normal 200
+    };
+    app._api = async (path: string) => {
+      calls.push(path);
+      return { ok: true, json: async () => ({ success: true, data: {} }) };
+    };
+
+    await app.runCustomModelEntry('claude', 'llama-box', 'qwen3');
+
+    const waitIndex = calls.findIndex((p) => p.includes('/wait?'));
+    const applyIndex = calls.findIndex((p) => p.endsWith('/custom-model'));
+    expect(waitIndex).toBeGreaterThanOrEqual(0);
+    expect(calls[waitIndex]).toBe('/api/sessions/new-session/wait?until=idle&timeout=20000');
+    expect(applyIndex).toBeGreaterThan(waitIndex);
+  });
+
   it('surfaces the real server error in the toast on a failed apply, rather than a generic message', async () => {
     const { app } = bootApp({});
     app.activeSessionId = 'old-session';