refactor(core): extract the session helpers and make the logger injectable

[Bccorb]

The two items that fell out of #72. Both are core hygiene, kept as separate commits.

Closes #136. Closes #137.

1. Session helpers (#136)

Seven handlers repeated the same block verbatim: verify the signed access token, check it describes the same subject as the response body, read the sid claim, then build the access and refresh cookie payloads.

Seven copies of a security-relevant check is seven chances to get an early return wrong, and the upstream fields were read untyped, so a rename on the API side would surface as an undefined cookie field at runtime rather than a type error.

setCookies: await issueSessionCookies(data, {
  authServerUrl: opts.authServerUrl,
  audience: opts.audience,
  accessCookieName: opts.accessCookieName,
  refreshCookieName: opts.refreshCookieName,
  cookieDomain: opts.cookieDomain,
}),

verifyUpstreamSession is exported separately for the one flow that verifies without issuing a session: login only sets the pre-auth cookie. switchOrganization reissues the access cookie without rotating refresh, which is now expressed by omitting refreshCookieName rather than by a differently shaped copy of the block.

The handlers drop 220 lines (271 deleted, 51 added across seven files).

One intentional behavior change

The access cookie from POST /webAuthn/register/finish now carries organizationId: null where it previously omitted the key.

That was the only inconsistency between the seven copies. Every other flow already included it, and ensureCookies writes organizationId: refreshed.organizationId ?? null on every reissue, so a registration session disagreed with itself after a single refresh. Both values are falsy and it converged on null anyway; it is now consistent from the start. Called out in the changeset.

2. Injectable logger (#137)

Core wrote to console directly at two sites. An adopter could not capture, level, or silence it, and an adapter with its own logger still leaked core's lines to console — one request producing output in two places, which the Fastify adapter made concrete since it logs guard rejections through request.log.

setSeamlessLogger(myLogger);   // anything with warn and error
setSeamlessLogger();           // back to console

Scope worth knowing: it is process-wide, not per-request, so it changes where diagnostics go rather than attaching request context to them. Core logs exactly two things — a failed signature verification and a misconfigured external-delivery setup — and neither depends on request context. Threading a per-request logger through every handler signature would be a much larger change, and I did not want to imply this delivers that.

grep console. packages/core/src now returns only the default logger's own implementation.

Tests

• upstreamSession.test.js: the sid claim present, absent, and non-string; both throw paths (unverifiable response, subject mismatch); verification against the configured server and audience; the access-only variant; and that no cookies are built from a response that failed verification.
• logger.test.js: the console default, an injected logger, resetting, a later swap taking effect, and that the delivery warning actually routes through it rather than to console.

Checks

pnpm build clean. pnpm test passes: 387 tests across the three packages, up 15.