chore(meta): add #627 SQLite settings storage to Sprint 26

Prerequisite for #646 (AI-Enhanced Dialogue toggle). Updated server
and client briefings with dependency chain and integration notes.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

docs/sprints/sprint-26/client.md

@@ -9,7 +9,7 @@
 
 | # | Title | Blocked by |
 |---|-------|------------|
-| #646 | UX: AI-Enhanced Dialogue toggle + hardware detection | #641 (done) |
+| #646 | UX: AI-Enhanced Dialogue toggle + hardware detection | #627 (server: SQLite settings storage) |
 
 Use `tooling/db/ticket show <id>` for full details.
 
@@ -20,12 +20,12 @@ Use `tooling/db/ticket show <id>` for full details.
 
 ## Notes
 
-- **#646 AI-Enhanced Dialogue toggle + hardware detection:** The voice pipeline (server-side, `server/src/voice/`) is wiring up this sprint via #652. The client needs layered hardware detection and player-facing controls so the feature degrades gracefully. Three detection layers in sequence: (1) CPU/RAM check — can the model even load? (2) time-per-token benchmark on first load — is it fast enough to be useful? (3) player-facing toggle — opt out even on capable hardware. The toggle state must persist (see #627 SQLite settings storage — not in this sprint, use a flat config file or `ProjectSettings` as interim). The UI for this is in the options/settings panel. Coordinate with server team: the client toggle must communicate to the server process whether voicing is requested (the server queue drains but does not requeue when disabled). Key integration point: `client/scripts/` settings panel and the existing `SR_LIVE` / subprocess launch flow. Check `docs/workshops/llm-voice-pipeline/` for hardware thresholds decided in the workshop.
+- **#646 AI-Enhanced Dialogue toggle + hardware detection:** The voice pipeline (server-side, `server/src/voice/`) is wiring up this sprint via #652. The client needs layered hardware detection and player-facing controls so the feature degrades gracefully. Three detection layers in sequence: (1) CPU/RAM check — can the model even load? (2) time-per-token benchmark on first load — is it fast enough to be useful? (3) player-facing toggle — opt out even on capable hardware. The toggle state must persist via #627 (SQLite settings storage, server team, same sprint). **Block on #627 landing before implementing the toggle** — the client sends a `ChangeSettings` command over IPC and the server persists it in SQLite. The UI for this is in the options/settings panel. Coordinate with server team: the client toggle must communicate to the server process whether voicing is requested (the server queue drains but does not requeue when disabled). Key integration point: `client/scripts/` settings panel and the existing `SR_LIVE` / subprocess launch flow. Check `docs/workshops/llm-voice-pipeline/` for hardware thresholds decided in the workshop.
 
 ## Dependency Chain
 
 ```
-#646 (UX toggle + hardware detection) — #641 done, unblocked
+#627 (server: SQLite settings) → #646 (UX toggle + hardware detection)
 ```
 
 ## PR Workflow

docs/sprints/sprint-26/server.md

@@ -15,6 +15,7 @@
 
 | # | Title | Blocked by |
 |---|-------|------------|
+| #627 | SQLite settings storage | — |
 | #650 | ContentType::Factual — LLM bypass for fact-bearing lines | — |
 | #652 | Voice pipeline: observer integration | #650 (preferred, not hard block) |
 | #655 | Remove v0.1 content loading system | — |
@@ -41,12 +42,15 @@ Use `tooling/db/ticket show <id>` for full details.
 
 - **#633 Composable behavior engine:** Current hand-authored behavior pools in `server/src/npc/routine.rs` enumerate culture×zone×role combinations, which won't scale to the generator. Goal: introduce a behavior primitive format (role action + culture modifier + context tag) and an assembly function that composes them at NpcBlueprint instantiation time. The `NpcBlueprint` struct in `server/src/npc/blueprint.rs` is the output target. Do not delete existing behavior pools until new assembly produces equivalent output — verify with an eyeball diff on generated behaviors for seed 42.
 
+- **#627 SQLite settings storage:** Persistent settings via SQLite on the server side (rusqlite with bundled feature — zero runtime dependency). Architecture: settings live on the SERVER in a SQLite database with per-player tables. The client sends `ChangeSettings` commands over IPC, same as any other player action. The client never touches the database directly. Scope: keybindings, audio volume, display preferences, accessibility options, AI-Enhanced Dialogue toggle. This must land before #646 (client toggle) so the toggle has a real persistence layer instead of a flat config file. Key integration point: the existing subprocess IPC in `server/src/bridge/`. The settings schema should be extensible (key-value with typed columns, not a single JSON blob) so future settings don't require migrations.
+
 - **#651 Friendly/RoutineDeviation tells — iterate post-ship:** Spike 2 showed these two tells produce output indistinguishable from neutral on Gemma 2B. Three options: stronger few-shot examples in the prompt, non-speech-act encoding (body language descriptions rather than dialogue register), or treat as a 2B capacity ceiling and defer to a larger model. Start with stronger examples (lowest cost). If no improvement after 3 prompt iterations, document the ceiling and close. This is a low-priority polish ticket — do not block sprint completion on it.
 
 ## Dependency Chain
 
 ```
 #650 (ContentType::Factual) → #652 (observer integration)
+#627 (SQLite settings) → #646 (client: AI toggle, cross-team)
 #633 (composable behavior engine) — parallel track, standalone
 #655 (remove v0.1 content loading) — parallel track, standalone
 #651 (tells iterate) — parallel track, standalone