Release v0.23.0: server-side sign-in state resume (#29)

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

CHANGELOG.md

@@ -23,6 +23,51 @@ skip versions are the composition of each intervening adjacent
 release's steps in order — no A-to-B path is pre-computed beyond
 that.
 
+## 0.23.0 — 2026-05-28
+
+Roadmap item #29: signing in lands the user on their most recently
+viewed app state instead of the empty-state home view. Shipped from
+driver session 0022.0. Per-user, server-side, on by default; first-ever
+sign-ins still land on home.
+
+1. **Server-side last-state.** A new `user_session_state` table holds one
+   row per user: `last_route TEXT`, `last_route_state TEXT` (light view
+   state encoded as JSON — SQLite has no native JSONB — never draft-buffer
+   contents), `resume_enabled INTEGER NOT NULL DEFAULT 1`, and
+   `last_updated_at`. Per-user (not per-device), matching the
+   "go to where I was last" intent.
+2. **Route-change capture.** A new frontend hook (`frontend/src/lib/
+   useLastState.js`) debounce-posts the current route + light state to
+   `PUT /api/me/last-state` for authenticated users only; anonymous
+   sessions are a no-op. The handler upserts the user's row and no-ops
+   when `resume_enabled` is 0.
+3. **Sign-in redirect.** The stored `last_route` (+ decoded state +
+   `resume_enabled`) is folded onto the existing `/api/auth/me` payload
+   (no new GET endpoint), so the frontend reads it on boot. On a hard
+   sign-in landing (app booted on `/`), the app redirects to the stored
+   route. The redirect is gated on the #21-Part-C Amplitude `identify`
+   having fired (`identifyReady`), preserving identify-then-track
+   ordering — the first event on the resumed route carries the user_id.
+4. **Edge cases.** Stale routes (an RFC since withdrawn or now
+   unreadable) are a graceful no-op — existing routing falls through to
+   the catalog/empty-state. Opt-out ships at the column level
+   (`resume_enabled`); the profile-settings toggle UI is a follow-up.
+   Stored state is route + light view state only, never draft contents
+   (documented in `SPEC.md` §6.8).
+
+Migration `022_user_session_state.sql` creates the table. No new
+environment variables, overlay keys, or secrets.
+
+Upgrade steps:
+
+1. Deployments **MUST** apply database migrations; `022_user_session_state.sql`
+   runs automatically on next boot (the migration runner globs
+   `backend/migrations/*.sql` and applies any not yet recorded in
+   `schema_migrations`). The migration is additive — a new table — and
+   requires no data backfill.
+2. No new environment variables, overlay keys, or secrets. No operator
+   action beyond the standard `flotilla deploy ohm-rfc-app`.
+
 ## 0.22.0 — 2026-05-28
 
 Roadmap item #26: an optional **"What will you be using this for?"**

VERSION

@@ -1 +1 @@
-0.22.0
+0.23.0

frontend/package.json

@@ -1,7 +1,7 @@
 {
   "name": "rfc-app-frontend",
   "private": true,
-  "version": "0.22.0",
+  "version": "0.23.0",
   "type": "module",
   "scripts": {
     "dev": "vite",