chore: bump to auth API v0.10.0, dashboard v0.5.0, templates v0.12.0

[Bccorb]

Moves the scaffold onto the current Seamless ecosystem.

Pin	Was	Now
SEAMLESS_AUTH_API_VERSION	v0.7.1	v0.10.0
SEAMLESS_AUTH_ADMIN_DASHBOARD_VERSION	v0.4.0	v0.5.0
SEAMLESS_TEMPLATES_REF	v0.9.0	v0.12.0
@seamless-auth/express (verify adapter)	^0.12.1	^0.13.0
@seamless-auth/fastify (verify adapter)	^0.3.1	^0.4.0

Auth API

Three releases land together. v0.8.0 gives WebAuthn challenges their own store with a five-minute expiry and one-time use, so a registration and a login can be outstanding at once instead of clobbering each other, and adds AUTHENTICATOR_POLICY (attachment, user verification, attestation, and whether a synced passkey may enrol). v0.9.0 puts the lockout policy and the per-IP and per-identity limiters on TOTP step-up, which carried none of the three, and stops running refresh tokens through bcrypt. v0.10.0 drops the sessions.refreshTokenHash column the previous release stopped writing.

A scaffold's compose file is built from the pinned release's .env.example, so a new project picks up AUTHENTICATOR_POLICY along with SESSION_IDLE_TTL, MAX_CONCURRENT_SESSIONS and a commented TRUST_PROXY, and REFRESH_TOKEN_TTL moves from 1h to 1d.

Admin dashboard

v0.10.0 of the API embeds dashboard v0.5.0 in its own image, so this bump keeps the standalone console (--admin=image and --admin=source) serving the same release as the one at /console. That release names the acting administrator separately from the subject in the events table, and collects identity proofing before preparing a device replacement.

Templates

v0.12.0 moves the starters onto @seamless-auth/react 0.11.0, @seamless-auth/express 0.13.0 and @seamless-auth/fastify 0.4.0 — all 0.x minors, so the caret ranges the starters carried could never have resolved to them. It also carries per-application auth cookie names read from AUTH_COOKIE_PREFIX. The manifest contract and the registry are byte-identical to v0.9.0, so nothing in init moves with it.

The conformance adapters follow the same SDKs the starters now install. Both stop repeating the access and refresh tokens in the body of the response that sets them as httpOnly cookies, and both forward a magic link's redirectUri to the API.

Verification

• Every target confirmed to exist rather than assumed: v0.10.0 and dashboard v0.5.0 are tagged on GHCR, and registry.json and .env.example fetch 200 at the new refs.
• npm view resolves ^0.13.0 / ^0.4.0 to 0.13.0 and 0.4.0.
• Ran the docker generator against the real .env.example at v0.10.0 to confirm the new keys reach the generated compose correctly escaped, AUTHENTICATOR_POLICY included.
• npm run build passes; 977 tests pass, 4 skipped.
• Diffed every template.json and registry.json between v0.9.0 and v0.12.0: no changes.
• Checked the adapter conformance specs for anything reading token / refreshToken off an adapter response, or asserting the 400 that core 0.13.0 turned into 401 — there is none; they assert cookies, and the one relevant case is .not.toBe(200).