Evict process-lifetime rate-limit and retry-hold maps in onboarding

[TheGreatAxios]

Summary

CL-7233: two in-memory maps in packages/onboarding grew for the life of the hub process with no eviction, plus an orphaned-retry-hold defect of the same class folded into this ticket.

• lastProvisionByUser (routes.ts) — one entry per distinct user who ever attempted named provisioning. Fixed by adding a new @corbits/collections package with createExpiringMap<K,V>, a TTL-eviction map (get() drops an expired entry lazily on read; set() opportunistically sweeps every expired entry once per TTL window, no background timer). The rate-limit window (10s) is the correct TTL here, since an entry has no reason to outlive the window it gates — this also let the manual now - lastAttempt < window comparison collapse to a plain get() !== undefined check.
• retryAfter/failureCount (bench-provisioning.ts) — consolidated into one holds map carrying userId/tenantId inline, and reclaimed once a bench's pending_seed row is confirmed gone (via store.read, not just absent from a given tick's listDue page) rather than only on convergence. A permanently-failing bench no longer leaves a stale backoff behind for a later, unrelated connect to the same user/tenant to inherit.

Why a new package

@corbits/collections exists so CL-7229 (orchestrator's postedApprovalIds/pendingDelegationThreads) and CL-7223 (folded-runs' crypto-provider cache) — the same bug class, called out explicitly in this ticket — have somewhere to land instead of each writing a third one-off bounded collection. apps/hub/src/launch-caches.ts's BoundedCache is a sibling primitive (size-capped LRU, no TTL, app-private) that predates this package; noting it here rather than touching it, since folding it in is out of scope for this ticket.

Eviction policy reasoning

• Rate-limit map → TTL. The map's only invariant is "how recently was this key touched"; an entry past the rate-limit window is worthless. TTL = the window itself.
• Retry-hold map → tie to the row's actual lifetime, not a TTL or LRU cap. An LRU cap risked evicting a hold for a bench that's still actively backed off, letting it get hammered again before its exponential backoff elapses. Confirming via store.read (authoritative regardless of listDue's paging) is slightly more expensive but provably correct rather than heuristic.

A bug found along the way (filed separately, not fixed here)

Greybeard's review of this approach surfaced that pending-seed.ts's listDue is not paginated across calls — a plain unordered LIMIT 50 re-scanned from the start of the table every tick, with no cursor. If outstanding pending_seed rows ever exceed 50, rows past that page are never drained until something ahead of them clears. This is a real, separate liveness bug, not something this ticket's outcome asked for — filed as CL-7252 rather than folded in here or dropped.

The store.read-based reconciliation in this PR is unaffected by that gap either way: it never trusts listDue's page as proof a row is gone, precisely because that page can't be trusted to be complete.

Test plan

• cd packages/onboarding && bun run typecheck && bun test — 165 pass
• cd packages/collections && bun run typecheck && bun test — 9 pass
• bunx prettier --check on all touched files
• bun run lint (root) — 0 errors
• Greybeard-reviewed design; Critique-reviewed both commit pairs, clean on the second pass

Stacking

This is PR 1 of 2 for CL-7233/CL-7234. CL-7234 (routing onboarding's caught errors through reportError) branches off this branch's tip — do not merge out of order.

Do not merge — flag if CI is red.