perf(ui): collapse the post-login first-load resolution chain and warm the agent base

[0xSolace]

The stall (fresh staging trace, 2026-07-22, build 050b263-era staging 11353ad7)

The demo path's post-login first load is a SERIAL resolution chain. Live canary-boundary trace (real CLI-session sign-in on app-staging.elizacloud.ai, renderer startup marks #9565 + network timings):

step	cost
token stored → /api/v1/user (status probe)	~0.8s
→ /api/v1/eliza/agents	~1.8s
→ bind → cold agent-base /api/auth/me	~2.3s
→ composer usable (firstLoadMs)	4.9–7.0s

Coordinator phase first-run-required → starting-runtime measured 9.9–10.4s across runs (includes the popup/session mint). Hydration itself is already off the critical path (#16885 pins it); this PR attacks the chain the F2-port receipts flagged as the real stall (FIRSTLOAD-REAL-2026-07-22).

Three chain cuts (listOrAutoProvisionCloudAgent / bindCloudAgent)

1. Stored bearer skips the status probe. getCloudStatus (→ /api/v1/user) ran before the agents list on every silent cloud entry. With a stored bearer, the agents list itself is the authoritative connectivity probe — and it's the data the bind needs anyway. Fetch it immediately and reuse it as knownAgents for selectOrProvisionCloudAgent, so the list is fetched exactly once (previously twice: once here, once inside the provisioning call). A failed list falls back to the status probe + login re-entry, so a stale/revoked token keeps the exact legacy recovery semantics.
2. No post-login status re-probe. After handleCloudLogin, the old code probed status again — and then overrode the result with getCloudAuthToken(client) anyway. The landed bearer IS the proof; the probe now runs only when no token landed (server-side-key logins), where its result still decides the outcome.
3. Warm the agent base at bind. The first request to a freshly bound cold cloud container pays connection setup + worker/container wake — measured 2.3s serialized behind persist → coordinator transitions → /api/auth/me. The bind now fires a fire-and-forget listConversations on the just-bound base so that cold cost overlaps the phases between bind and hydrate; the hydrate-phase fetch remains authoritative, failures are irrelevant, and client shims without the chat surface no-op.

Regression test — structural, not timing-based

first-run-finish.firstload-chain.test.ts (7 tests), pinning the shape so it can't flake:

• bearer path: zero status probes, one list fetch, knownAgents reuse verified on the provisioning call
• stale-bearer degrade: failed list → status probe → login re-entry (never strands)
• post-login: exactly one status probe total when a token lands; needs-cloud-login preserved when neither token nor probe succeed
• warm-up: fired on the bound base, non-blocking on reject, safe no-op without the surface

One existing conductor test updated (pre-opens the Cloud auth window…): its suite-level beforeEach plants a stored bearer, which now correctly short-circuits login before any popup — the test clears it, since the popup path is only reachable when login is genuinely needed.

Verification

• packages/ui first-run suite: 27 files / 346 tests green (includes the reused-shared-handoff contract suite over the edited function)
• useCloudState same-tab + stale-login suites, hydrate-nonblocking (test(ui): non-blocking startup hydration invariant — first usable load (first-5 strike F2 port) #16885), App.chat-overlay-first-run: green
• bunx tsc --noEmit (ui): clean · biome: clean
• New test fails against unpatched first-run-finish.ts (4/7 fail: status-probe counts + warm-up), passes with it

Coordination

• No registry/AppManager scope — nubs' fix: cold first message turn no longer blocks on registry refetch and duplicate cloud billing calls #16873 cold-path territory untouched (this is entirely packages/ui first-run/bind).
• No overlap with fix(cloud): sliding-TTL scope-cache refresh — kill residual cold-turn stall on idle-paced chat #16785 (scope-cache TTL) / fix(cloud): shared-agent conversations 500 + PWA init hang + SW auto-update (3-commit strike) #16837 (Date rehydration) server code.
• No workflow files. Test-plus-code change in one module + one test-only edit.

Expected canary movement: removes ~2.6s of serial round trips from firstLoadMs and overlaps the ~2.3s cold agent-base wake; targets the staging load budget ≤5s.

Receipts: projects/eliza-fleet/FIRSTLOAD-REAL-2026-07-22.md (trace before/after + method).

[sol-firstload-real]

Evidence Gate

• Before screenshots N/A - no visual surface change; pure .ts startup-flow logic (no .tsx/.css touched). The "before" is the network trace below.

• After screenshots N/A - no visual surface change; acceptance is the staging canary firstLoadMs budget post-deploy.

• Walkthrough video N/A - no user-visible flow change; identical screens, fewer serial round trips behind them.

• Backend logs N/A - no backend/server code changed; client-side request-ordering only.

• Frontend console/network logs: real staging network trace captured at the canary boundary (Playwright, real CLI-session sign-in, https://app-staging.elizacloud.ai): req=11831 res=12590 200 GET /api/v1/user (status probe ~0.8s, removed on bearer path) → req=12591 res=14382 200 GET /api/v1/eliza/agents (~1.8s, now the probe itself, fetched once + reused as knownAgents) → req=14424 res=16742 200 GET <agent>.staging.elizacloud.ai/api/auth/me (~2.3s cold wake, now overlapped by the bind warm-up) → composer usable at 16792 (firstLoadMs 4930ms). Full JSON trace + renderer startup marks archived in the fleet lane receipt (domain-artifacts row). Structural after-proof: first-run-finish.firstload-chain.test.ts 7/7 green, 4/7 fail against the unpatched module.

• Real-LLM trajectory N/A - no agent/action/provider/prompt/model change; UI startup resolution order only.

• Domain artifacts: trace method + before/after receipts in the fleet lane deliverable projects/eliza-fleet/FIRSTLOAD-REAL-2026-07-22.md (workspace, referenced from Discussion 🤖 Agent Fleet — Coordination HQ (guidelines + standup) #14308); probe script is the F2-port trace probe (Playwright vs https://app-staging.elizacloud.ai) with per-request issue timestamps. No DB/wallet/generated-file artifacts apply to a client request-ordering change.

[lalalune]

Reviewed + adversarially re-verified: the removed post-login /api/v1/user probe result was genuinely dead (overridden by getCloudAuthToken), knownAgents reuse plumbing verified end-to-end on develop, listConversations warm-up is read-only/optional-chained, base blobs match current develop head (post-6f93b6a3da, no overlap with the startup auth prime gate). All checks green at verification. Squash-merging. [pr-queue-review]