`sbx create` re-authenticates to Docker Hub on every create, serializing concurrent creates

[alexander-turner]

Version: sbx v0.39.0, Linux x64 (GitHub Actions Ubuntu runners, KVM available), authenticated via sbx login with a Docker Hub PAT.

Reproduction

sbx login once, then start ~8 sbx create calls concurrently (same image, already pulled).

Observed

Each create stalls 40–70 s before its VM boots, and the creates make progress one at a time rather than in parallel. A 20-create run (one create per eval sample) eventually received an HTTP 429 from Docker Hub and lost the 19th create, even though the image was already local. The one-at-a-time timing suggests the daemon takes a shared lock while it refreshes its Hub token, and refreshes on every create — we have not read the daemon source, so the lock is inferred from timing, not confirmed.

Expected

The daemon caches the Hub token after the first successful authentication and reuses it for its validity window, so N creates cost ~1 authentication and are limited only by VM boot time.

Suggested fix

Store the token and its expiry after the first auth; take the refresh path only when the cached token is absent or expired. sbx login with new credentials should invalidate the cache. An expired token mid-run then refreshes once, which matches today's behavior for that single create.

Notes

• Related: sbx diagnose refreshes Hub credentials on every call #402 — the CLI reports a Hub 429 as "service unavailable", which is how the rate-limit failure above first surfaces to a caller.
• v0.39.0's platform.images.registryMirror mitigates pull-side rate limits but not this auth-side traffic.