feat: exercise the Fastify starter in the verify harness

[Bccorb]

Closes #147.

The scaffold has offered a Fastify API since the templates bump in #146, but the conformance harness only ever drove the Express adapter. A green seamless verify said nothing about whether a Fastify-scaffolded project actually worked.

Result

Verified locally against the real stack (seamless verify --no-react, exit 0, 24 passed):

  flow            api   adapter   adapter-fastify   react
  ----------------------------------------------------------
  emailOtp        ✓     ✓         ✓                 -
  jwks            ✓     -         -                 -
  magicLink       ✓     ✓         ✓                 -
  oauth           ✓     ✓         ✓                 -
  organizations   ✓     -         -                 -
  ownerAdmin      ✓     -         -                 -
  phoneOtp        ✓     -         -                 -
  register        -     ✓         ✓                 -
  session         ✓     ✓         ✓                 -
  stepUp          ✓     -         -                 -
  totp            ✓     -         -                 -

Fastify passes the same five cookie-path flows as Express, and a regression in either is attributable to that framework.

How

verify/adapter-fastify-app (port 3001) is a deliberate twin of the Express adopter backend: same routes, same env contract, same capture transport, so a spec cannot tell which one answered. Two differences the framework forces, both commented in place:

• The Fastify adapter takes no issuer option (the Express one does); audience is what both check API-signed tokens against.
• Fastify binds loopback by default, which is unreachable once the port is published out of the container, so it binds 0.0.0.0.

The specs are not duplicated. Both adapter projects run the same files from ./adapter and differ only in an adapterUrl project option (lib/fixtures.ts). Adding an adopter framework is a project entry plus a compose service, never a copy of the suite.

matrixReporter now takes the layer from the Playwright project name, not the spec's path. The two projects share a directory, so the path can no longer identify the layer. Columns size to their own headers so adapter-fastify doesn't collide with the next one.

--local builds and packs @seamless-auth/fastify alongside core and express, with core packed into both vendor dirs since each image installs it beside its own adapter. That fan-out is asserted in a unit test rather than left to the next --local run to discover.

--api-only and --no-react are unchanged.

Notes

• Pinned @seamless-auth/fastify@^0.3.1, above the 0.2.0 floor the issue called for (console proxy support). The summary output reports the pin alongside the Express one.
• The issue flagged the per-IP OTP limiter as a risk with a second adapter funnelling OTP through one IP. It did not bite: the compose stack sets DISABLE_AUTH_RATE_LIMITS=true, and the adapter suite already prefers magic-link over a second email-OTP round trip.
• The Fastify starter is still beta in the registry; this does not change that, it just means the beta is now conformance-tested.

Checks

npm run build, npx tsc --noEmit in the harness, and npm test (815 passed, 4 skipped) all pass. The live run above is the meaningful one. Rebased onto 0.11.0.