Robustness: WAL mode, security headers, last-login, delete-my-account

SQLite WAL mode (start9/0.4/docker_entrypoint.sh)
- Switches journal_mode to WAL on every boot. WAL persists in the DB
  header so this is effectively a one-shot but rerunning is harmless.
- Crucial for the "background StartOS Backup while users are using the
  app" case: under the default rollback journal, a long backup can
  capture an inconsistent snapshot. WAL keeps readers and the writer
  from blocking each other.
- synchronous=NORMAL paired with WAL: still crash-consistent at every
  checkpoint, ~10x faster than FULL.

Security headers (proof-of-work/next.config.js)
- Content-Security-Policy with frame-ancestors 'none', base-uri 'self',
  form-action 'self', object-src 'none'. Keeps 'unsafe-inline' for
  script/style because Next.js emits inline bootstrap; tightening to
  nonce-based CSP is a follow-up.
- Strict-Transport-Security: max-age=31536000; includeSubDomains.
- Referrer-Policy: strict-origin-when-cross-origin (don't leak workout
  IDs etc. to third-party sites).
- Permissions-Policy: deny camera, mic, geolocation, USB, etc. across
  the board (none of those APIs are used today; explicit deny means
  vulnerability scanners have one less thing to flag).

Last-login tracking
- New User.lastLoginAt column. createSession stamps it inside the same
  transaction as the new Session row.
- Compat ALTER in entrypoint adds the column to legacy snapshots.
- Admin Users table now shows a relative-age cell (today / Nd ago /
  Nmo ago / Ny ago / "never" if the user hasn't signed in since the
  column was added). Hover reveals the exact ISO timestamp.

Self-serve delete-my-account (Settings -> Danger Zone)
- Requires both the user's current password AND typing the literal
  phrase "delete my account" (defense against a stolen-session
  attacker nuking the account in one click).
- Refused for the last admin (instance can't be left with no admin —
  the user is told to promote someone first).
- Cascades through Prisma onDelete: Cascade on every relation owned by
  User, so workouts, exercises, sessions, preferences all go in one
  shot. Session cookie cleared, redirected to /auth/login.

start9/0.4/docker_entrypoint.sh

@@ -91,6 +91,11 @@ if command -v sqlite3 >/dev/null 2>&1 && [ -f "$DB_PATH" ]; then
          AND NOT EXISTS (SELECT 1 FROM User WHERE isAdmin = 1);"
   fi
 
+  if ! sqlite3 "$DB_PATH" "PRAGMA table_info('User');" 2>/dev/null | grep -q "|lastLoginAt|"; then
+    log "adding missing column User.lastLoginAt (nullable)"
+    sqlite3 "$DB_PATH" "ALTER TABLE User ADD COLUMN lastLoginAt DATETIME;"
+  fi
+
   if ! sqlite3 "$DB_PATH" \
     "SELECT name FROM sqlite_master WHERE type='table' AND name='InstanceSettings';" \
     2>/dev/null | grep -q InstanceSettings; then
@@ -104,6 +109,20 @@ if command -v sqlite3 >/dev/null 2>&1 && [ -f "$DB_PATH" ]; then
     sqlite3 "$DB_PATH" \
       "INSERT OR IGNORE INTO InstanceSettings (id, signupsOpen) VALUES (1, 0);"
   fi
+
+  # SQLite tuning. Enabling WAL means readers don't block on a concurrent
+  # writer (and vice versa) — crucial for the "background StartOS Backup
+  # while users are using the app" case, which under the default rollback
+  # journal can produce a torn snapshot. journal_mode persists in the DB
+  # header once set, so this is effectively a one-shot. synchronous=NORMAL
+  # is the safe-with-WAL balance: no fsync after every commit but still
+  # crash-consistent at every checkpoint, ~10x faster than FULL.
+  current_mode=$(sqlite3 "$DB_PATH" "PRAGMA journal_mode;" 2>/dev/null || echo "")
+  if [ "$current_mode" != "wal" ]; then
+    log "switching SQLite journal_mode from '${current_mode:-unknown}' to WAL"
+    sqlite3 "$DB_PATH" "PRAGMA journal_mode=WAL;" >/dev/null
+  fi
+  sqlite3 "$DB_PATH" "PRAGMA synchronous=NORMAL;" >/dev/null
 fi
 
 # -----------------------------------------------------------------------------