Add account profile password change flow

CHANGELOG.md

@@ -2,6 +2,8 @@
 
 ## Unreleased
 
+- Added an authenticated account profile route with safe account metadata and
+  password-change handling.
 - Implemented an explicit browser-cookie auth client mode with in-memory CSRF
   handling.
 - Enabled live owned-incident listing against authenticated

README.md

@@ -113,8 +113,6 @@ Planned account portal work includes:
 - public landing and pricing/account-entry pages
 - payment-gated account creation
 - login/logout
-- account profile page
-- password change flow
 - session status and session revocation flows
 - account billing status display
 - subscription/payment status handling
@@ -264,13 +262,18 @@ do not imply production readiness or public `/v1` API readiness.
 
 The server currently confirms bearer session auth, browser-cookie auth routes,
 `POST /v1/auth/register`, `POST /v1/auth/email/verify`, `GET /v1/account`,
-owner-scoped incident list/detail routes, contact public-key routes,
-sharing-grant routes, and wrapped-key routes. Current `open-proofline/server`
-documents authenticated
+`POST /v1/account/password`, owner-scoped incident list/detail routes, contact
+public-key routes, sharing-grant routes, and wrapped-key routes. Current
+`open-proofline/server` documents authenticated
 `GET /v1/incidents`, and this client parses that response shape in live mode.
 Mock mode uses prototype incident records only and must not be treated as
 backend truth.
 
+Authenticated users can open the account profile route to review safe account
+metadata and change their password through `POST /v1/account/password`. The
+server keeps the active session usable after a successful password change and
+revokes other sessions for the account.
+
 Public registration is controlled by the server's
 `SAFE_ACCOUNT_REGISTRATION_MODE`. `disabled` and `admin_only` reject public
 registration with `registration_disabled`; `open` creates a

docs/api-client.md

@@ -36,6 +36,7 @@ From current `open-proofline/server` docs and route registration:
 - `POST /v1/auth/web/logout`
 - `GET /v1/auth/web/csrf`
 - `GET /v1/account`
+- `POST /v1/account/password`
 - `POST /v1/incidents`
 - `GET /v1/incidents`
 - `GET /v1/incidents/{incident_id}`
@@ -56,6 +57,18 @@ The web client calls `GET /v1/incidents` in live mode and parses the
 still returns typed prototype incident records for browser smoke tests and UI
 review, but those records are not backend truth.
 
+## Account Profile And Password Change
+
+The account profile route reads safe account metadata from `GET /v1/account`.
+Password changes call authenticated `POST /v1/account/password` with
+`current_password` and `new_password`, parse the returned `{ "account": ... }`
+body, and keep the current browser session active. Current server behavior
+revokes other sessions for the account after a successful password change.
+
+The UI maps password-change failures to fixed safe messages and does not log or
+persist passwords, request bodies, session tokens, Authorization headers,
+browser session cookies, or CSRF token values.
+
 ## Frontend Metadata Boundary
 
 Incident detail parsing keeps browser state focused on public-safe metadata.

docs/architecture.md

@@ -13,8 +13,8 @@ flowchart LR
 
 ## Boundaries
 
-- The app handles account login, public registration, email verification, and
-  incident metadata review.
+- The app handles account login, public registration, email verification,
+  account profile/password management, and incident metadata review.
 - The live API client supports explicit bearer-token and browser-cookie auth
   modes. Cookie mode uses server-managed HttpOnly cookies, in-memory CSRF
   tokens, and `credentials: "include"` only for cookie-authenticated requests.

docs/security-model.md

@@ -12,6 +12,8 @@ This web client is experimental and not production-ready.
 - Expired or malformed loaded sessions are cleared before authenticating the UI.
 - Loaded sessions are cleared when the configured API mode or auth mode no
   longer matches the stored session metadata.
+- Password changes use the authenticated account route, keep the active session
+  usable after success, and rely on the server to revoke other account sessions.
 - API responses are parsed with Zod before use where route shapes are known.
 - UI states avoid showing raw tokens, Authorization headers, request bodies,
   plaintext, raw keys, wrapped-key ciphertext, stored paths, or object keys.