feat(sessions): bound how many sessions one user may hold at once

[Bccorb]

Closes #176.

Blocked on a release. This needs @seamless-auth/types@0.16.0, which is
fells-code/seamless-auth-types#54. package.json asks for ^0.16.0 but the
lockfile still pins 0.15.0, so CI will fail on npm ci until that publishes.
Run npm install here once it does. I verified locally against the types build
from that branch: typecheck, lint, format, build, 1171 tests and coverage all
pass.

What was wrong

issueSessionAndRespond created a session on every successful authentication and
never looked at the ones already there, so nothing bounded the count. NIST 800-53
AC-10 asks for exactly that bound, and it is an operational problem wherever
workstations are shared, since an unbounded count leaves sessions alive on
machines a user has walked away from.

The setting

max_concurrent_sessions defaults to no limit, so an instance predating it is
unaffected, which is the acceptance this issue asked for.

Unlimited is null rather than 0, and the schema refuses 0. Zero would
otherwise read as "no sessions allowed", which is a plausible way for an operator
to try to remove a cap and lock every user out instead.
MAX_CONCURRENT_SESSIONS also accepts an empty value, null, none or
unlimited, because a deployment template cannot easily unset a variable.

The behaviour

At the limit the sign-in succeeds and the user's oldest session is revoked
with revokedReason: 'concurrent_session_limit', recorded as a new
session_evicted auth event naming the session that ended.

Refusing the new session was the alternative. It locks a user out of the device in
front of them until something they may not have access to expires, which for the
shared workstations this exists to protect is the common case rather than the edge
one.

Three details worth reviewing:

• It runs before the new row is created, so the limit counts the session about
  to exist. At a limit of 3, a user holding 3 ends up with 3, not 4. There is a
  test asserting that ordering rather than just the call.
• Lowering the limit converges in one pass. A deployment that drops the cap
  leaves users above it; the next sign-in evicts everything above it rather than
  shedding one session per login forever.
• It never throws. A session that cannot be revoked is logged and the sign-in
  continues, because failing an authentication over a housekeeping step is worse
  than briefly exceeding the cap. Covered by a test.

An uncapped deployment does not even run the query, so this costs nothing on the
default path.

Ripple

Contract-affecting, as the issue anticipated. @seamless-auth/types gains the key
(#54 there), which the admin dashboard picks up for free once it takes the
release. No route, status code or token change here. session_evicted is a new
auth event type, categorised under login, which is where session lifecycle
already lives since logout_ maps there.

Checks

npm run typecheck, npm run lint, npm run format:check, npm run build,
npm run test:run (1171 passing) and npm run coverage all pass locally against
the types branch build. openapi.json and src/generated/api.ts regenerated.

[Bccorb]

Unblocked and out of draft.

One correction: the key shipped in 0.17.0, not 0.16.0. 0.16.0 was already
published with the WebAuthn error code union, so the release carrying
max_concurrent_sessions landed a version later than my pin assumed. I checked
both rather than guessing:

0.16.0 occurrences of max_concurrent_sessions: 0
0.17.0 occurrences of max_concurrent_sessions: 4

package.json and the lockfile now take ^0.17.0 from npm, and the changeset
names the right version.

Re-verified against the published package rather than the local build I developed
against: npm run typecheck, npm run lint, npm run format:check,
npm run build, npm run test:run (1171 passing) and npm run coverage (98.78%
statements, above every threshold) all pass. openapi.json and
src/generated/api.ts regenerate byte identical, so the published contract is
unchanged by the dependency move.