/**
 * Tests for the cold-start `TokenManager` priming step (APPS-4231 follow-up).
 *
 * Background
 * ----------
 * `NpmRegistryClient.getJwt()` (`packages/vite-plugin-file-sync/src/ai-service/index.ts`)
 * has two bearer-credential sources:
 *   1. `tokenManagerJwt`, seeded synchronously at `AiService` construction
 *      from `tokenManager.getCurrentToken()` and kept current via the
 *      `tokenUpdated` listener for future refreshes.
 *   2. `clark?.context?.jwt`, primed lazily by the first socket RPC's
 *      `peerAuthorization` header (`socket-manager.ts`).
 *
 * `TokenManager.updateToken()` has exactly one production writer outside
 * `dev()` itself: `AuthHotReloadServer` (`auth-hot-reload.mts`). That socket
 * is explicitly disabled on live-edit pods (SABS sets
 * `SUPERBLOCKS_AUTH_HOT_RELOAD=false`). So on cold start neither source is
 * primed until the UI socket lands — which is AFTER `syncHomeNpmrc` and
 * AFTER the AiService's `TemplateRenderer` prefetch fires.
 *
 * The CLI does have a usable token in scope at `dev()` entry
 * (`tokenConfig.token`, sourced from auth.json or `/_sb_activate`).
 * `primeTokenManagerWithInitialToken` seeds it. Because `TokenManager`
 * retains the current token as state and consumers read it synchronously
 * during construction (see `getCurrentToken()` on `ITokenManager`), the
 * call-site ordering between the prime and consumer construction is NOT
 * load-bearing: the seed reaches AiService whether the prime fires before
 * or after `new AiService(...)`.
 */
export {};
//# sourceMappingURL=dev-token-priming.test.d.mts.map