Tool search stops crashing when many large catalogs are stale

[fforres]

What users see

Before this change, tool search on this host failed with "Execution lost: the session was reset" whenever many connections had stale catalogs at once, for example several large OpenAPI specs. After the crash, the unfinished-attempt backoff skipped those connections, so their catalogs never got built: a connected integration listed zero tools. With this change, search answers from the stored catalogs, and stale catalogs rebuild one at a time in the background until they all converge.

What changed

1. Merge upstream/main into skyward (22 commits, one merge commit, no rebase). This includes Scope toolkit tool reads and stop gating reads on TTL-expired catalogs UsefulSoftwareCo/executor#2061: reads no longer wait on TTL-expired catalogs, and connection/integration lists do not wait on syncs. Two conflict hunks in packages/core/sdk/src/executor.ts were resolved by keeping both sides:
   • stampSyncedWithHealth keeps our tools_sync_started_at: null and takes upstream's new last_health shape.
   • syncStaleConnectionTools takes upstream's urgent/deferred structure, with our crash-loop breaker re-applied inside its loop.
2. Bounded background rebuilds (c74b3a5ce). Scope toolkit tool reads and stop gating reads on TTL-expired catalogs UsefulSoftwareCo/executor#2061 alone does not fix this crash: OpenAPI catalogs have no TTL, so a stale-marked one takes the urgent path and still rebuilds 10 at a time inside the session Durable Object.
   • New ExecutorConfig.toolsSyncConcurrency, an executor-wide semaphore around background rebuilds. The SDK default stays 10; host-cloudflare sets 1.
   • The permit is taken inside the single-flight run, so a later read joins a queued rebuild instead of queueing a copy.
   • The breaker no longer treats a rebuild still running in this executor as a dead attempt.
   • A retry of an attempt that died goes to the back of its queue, so one catalog that kills its instance cannot keep the others from building.
   • Urgent rebuilds start first, so the read's grace wait is spent on the catalogs it waits for.
3. Type-only fix in github-app.ts (Uint8Array<ArrayBuffer>). The sdk typecheck already failed without it.

No D1 schema changes.

Testing

• New tests in connections.test.ts: with 5 stale connections, a concurrency of 1 and two overlapping reads, both reads return from the stored rows, at most one rebuild runs at a time, and each catalog rebuilds exactly once. A connection whose earlier attempt died rebuilds after the healthy one. Both tests fail with the fix removed.
• Package tests: core/sdk 959, core/api 132, plugins/openapi 337, plugins/mcp 317 (29 skipped), plugins/toolkits 6, hosts/cloudflare 129, apps/host-cloudflare 60. All pass.
• bun run typecheck: 44 of 45 packages pass. @executor-js/desktop fails the same way on skyward (two vite copies).
• Lint is clean. format:check fails on the same 6 files as on skyward, none of them touched here.
• host-cloudflare bun run build passes, including assert-shell-asset.

Risks

• Connections already stamped by the crash stay skipped until their 15-minute backoff ends, then rebuild one at a time.
• If a single catalog cannot fit in one session's memory on its own, it still crashes every 15 minutes, but it no longer blocks the others. Fixing that would mean moving rebuilds off the session Durable Object.
• With a limit of 1, many stale MCP catalogs converge more slowly. A read still waits at most the 2 s grace budget.

[fforres]

Superseded by #7: same code (identical tree at the bounded-rebuild commit), landed as a rebase of our patch stack onto upstream main instead of a merge, plus rebuild and Jev logging.