[ayuxy027]

Closes #199

What

Adds DELETE /api/session. It runs behind the existing /api/* auth middleware, so only a valid session can call it, and it deletes the caller's own session row (system/sessions, keyed by the token digest, the same lookup Auth.owner uses). Once revoked, the token returns 401 on every route. Other sessions are untouched.

Also cleans up expired sessions. Before this change, Auth.owner returned 401 for an expired session but kept its row, so every sign-in that was never revoked left a dead row behind permanently. It now deletes the row when it rejects it as expired, best-effort so a failed cleanup still returns the intended 401. This is housekeeping, not a security fix. A row that expires and is never presented again still stays; a periodic sweep would cover that case but needs new Store surface, so it's out of scope here.

• apps/server/src/auth.ts: Auth.revoke(authorization), which uses db.remove; Auth.owner removes a session row it finds expired
• apps/server/src/app.ts: the route, registered after the auth middleware
• tests/api.test.ts:
  • signs in with a second session, revokes it, and checks that the revoked token gets 401 on /api/workspace and on a repeat DELETE, while the original session still gets 200
  • expires a session, checks the request gets 401, and checks that the row is gone. This test fails against the previous auth.ts.
  • makes the cleanup delete fail and checks the request still gets a clean 401 (the cleanup is best-effort and must not turn the rejection into a 5xx)

Client sign-out wiring is left for a follow-up.

Tested

• pnpm lint, tsc --noEmit
• pnpm test: 490 passed, 0 failed
• Server-only change, so the native/web builds and browser suites weren't run