chore: move the scaffold onto the current ecosystem and offer Fastify

[Bccorb]

Bumps the pinned ecosystem so seamless init scaffolds from the current releases, and adds Fastify as a backend option.

Pin	Was	Now
SEAMLESS_AUTH_API_VERSION	v0.5.0	v0.7.0
SEAMLESS_AUTH_ADMIN_DASHBOARD_VERSION	v0.3.0	v0.4.0
SEAMLESS_TEMPLATES_REF	v0.5.0	v0.8.0
@seamless-auth/express (conformance adapter)	^0.9.0	^0.12.0

Templates v0.8.0 carries @seamless-auth/react ^0.8.0 in both React starters, @seamless-auth/express ^0.12.0 in the Express starter, and @seamless-auth/fastify ^0.3.0 in the Fastify starter.

Registration without a passkey

Registration used to end on a screen with one control. A user who did not want a passkey, or whose device could not make one, had no way forward. The starters now offer a skip when the instance has another login method enabled, and say so plainly when it does not.

That path only works if the whole chain moves together, which is why this bumps them as a set:

• The auth API adds an unauthenticated GET /system-config/public returning the configured loginMethods and nothing else (v0.7.0).
• The adapters serve routes from an explicit list, so they had to add the proxy (@seamless-auth/express 0.12.0, @seamless-auth/fastify 0.3.0).
• The React starters read it to gate the skip control (@seamless-auth/react 0.8.0).

A web template upgraded on its own would read nothing and show no skip at all. This also fixes a real mismatch: the React SDK previously fell back to a hardcoded ['passkey', 'magic_link', 'phone_otp'], so a client could advertise a method the instance had turned off.

Fastify

seamless init offers a second backend, listed as "Fastify (beta)" beside Express. It serves the same surface as the Express starter on an identical env contract, including the admin console at /console behind SERVE_ADMIN_CONSOLE.

This needed no CLI code. The backend prompt builds its options from the registry and already renders a beta status as a (beta) suffix without disabling the entry, and requires.cliMin (0.10.0) is satisfied by 0.10.2. Verified through the real code path at the new ref:

api options as the prompt renders them:
  - Express  (id=express)
  - Fastify (beta)  (id=fastify)

Two boot-time fixes land with v0.8.0: an empty PORT= in .env now falls back to 3000 rather than binding a random free port, and pino-pretty moves to a runtime dependency so an install without dev dependencies boots.

What else users get

Both React starters gain a protected /session route showing the issued claims, roles, organization context, step-up freshness, and registered passkeys, so the first authenticated screen reads as an app rather than a JSON.stringify dump. Missing configuration now stops a scaffolded project with a message naming the variable instead of surfacing later as a 500.

The auth API drops the admin bootstrap invite flow in favor of the OWNER_EMAIL grant the CLI already writes, so generated .env files no longer carry SEAMLESS_BOOTSTRAP_ENABLED, SEAMLESS_BOOTSTRAP_SECRET, or SEAMLESS_AUTH_DEBUG_SECRETS. AVAILABLE_ROLES now offers admin:read and admin:write, and Postgres TLS is configurable through DB_SSL, DB_SSL_CA, and DB_SSL_REJECT_UNAUTHORIZED.

Both API starters ship .env.example secret placeholders long enough to clear the adapter's 32 character minimum, so the documented cp .env.example .env && npm run dev path boots. A project from seamless init was already unaffected, because the CLI fills COOKIE_SIGNING_KEY itself.

Why the rest needed no CLI code

• The API's standardized error shape consolidates onto { error }. loginFlow.ts and systemConfig.ts already read error first.
• New env reaches generated projects on its own: the CLI fetches .env.example at the pinned tag and mutates the parsed result, so AVAILABLE_ROLES and the DB_SSL* keys flow through. v0.7.0 changed no env at all.
• OWNER_EMAIL generation was already in place and was already supported by v0.5.0 (in src/lib/ownerAdmin.ts), just undocumented. Nothing was broken before this bump.
• GET /system-config/public is consumed by the React SDK, not by the CLI. The CLI's own config command talks to the admin routes, which are unchanged.

Checks

npm run build clean, 691 unit tests pass, verify/harness tsc --noEmit clean.

Conformance passed on all three layers against auth API 0.7.0, @seamless-auth/express ^0.12.0, and @seamless-auth/react ^0.8.0, using clean checkouts at the pinned tags:

  ✔  API / adapter                 6.2s
  ✔  Web · react-vite (all flows)  11.5s
  ✔  Web · react-oauth (@oauth)    1.7s
  ✔ Conformance passed — 3 layer(s).

Two caveats on coverage, both worth knowing rather than blocking:

• The harness has no Fastify layer. Its adapter app is Express only, so the Fastify starter is not exercised here. Tracked in feat: exercise the Fastify starter in the verify harness #147. The parity suite in seamless-auth-server asserts the two adapters return identical status, body, and Set-Cookie headers, including the console proxy, which is the current basis for confidence.
• Verify builds the api and react layers from sibling working trees, not from the pinned refs. A checkout behind the tag will silently test the wrong source; the packages block in the summary reports the versions it actually used, which is the tell. The run above used clean v0.7.0 and v0.8.0 checkouts via SEAMLESS_API_DIR and SEAMLESS_TEMPLATES_DIR.