Provide an API for an authenticated route to end all sessions of a different user

[jmirchandani]

There is no supported way for server-side code (core or a plugin/auth-provider route) to
invalidate a session belonging to a different user than the one making the request. This
blocks a standard security operation: forcing out an already-issued session after an admin
resets that user's password, disables their account, or responds to a suspected compromise.

What I found, checked against main

• No session repository/table exists in core. packages/core/src/database/repositories/
  has no file matching *session* — no sessions table anywhere in core's schema.
• Sessions are read per-request via Astro's own session store, not a core-owned table.
  packages/core/src/astro/session-user.ts:34-57 (resolveSessionUser()) resolves the current
  user by calling session.get("user") on the request's own Astro session object — a
  request-scoped read, not a lookup into a cross-request-addressable store core exposes to
  route handlers. There's no "get/list/delete sessions for user X" function anywhere in
  packages/core/src (searched for invalidateSession, revokeSession,
  invalidateAllSessions, deleteSessionsFor — no hits).
• I hit this building an auth-provider plugin: an admin "reset a user's password" action
  replaces the stored credential immediately (old password stops working for future logins)
  but can't terminate a session the target user already has open in their browser. I don't
  think a plugin should try to build a shadow, plugin-owned session-tracking system to work
  around this — it would duplicate core's session model without visibility into how core
  actually issues or validates sessions.

Requested API (shape, not a full spec — open to whatever design fits core best)

Something callable from an authenticated admin route, e.g.:

// packages/core/src/api/route-utils.ts (or a new session-management export)
export async function invalidateAllSessionsForUser(
  emdash: EmdashLocals,
  userId: string,
): Promise<void>;

Astro's session abstraction is store-pluggable (cookie-backed, KV-backed, etc. depending on
adapter), so the exact mechanism will differ by deployment — but a documented extension point
(even one that only works on a subset of session-store backends and clearly reports when it
can't act) would be strictly better than no API at all.

Who else this affects

Any auth-provider extension implementing password reset, account disable, or a similar
admin-acts-on-another-user flow hits the same gap. It isn't specific to one plugin. The
built-in Passkey provider doesn't appear to have an equivalent "admin resets a credential for
someone else" flow today, but would hit this if one were added.