feat: add Prism snake and gameplay database lifecycle

- Add bitboard-accelerated Prism and versioned Supreme snake implementations.
- Add database-backed move benchmarks and focused strategy tests.
- Normalize gameplay storage while preserving replay compatibility.
- Add deterministic game quality scoring and replay retention tiers.
- Add backup-first SQLite cleanup, verification, and replacement tooling.
- Add safe compact-plus-delta database merging with conflict detection.
- Extend SQLite and PostgreSQL schemas for replay and quality metadata.
- Add PostgreSQL development service and pytest import configuration.
- Update gameplay documentation and the quart_common submodule revision.

README.md

@@ -75,6 +75,76 @@ BATTLE_SNAKE_DUEL_STYLE=balanced python main.py
 
 Allowed values: `safe`, `balanced`, `aggressive`.
 
+## PrismBattleSnake_GPT_5_6_Sol
+`PrismBattleSnake_GPT_5_6_Sol` is a separate snake that keeps Apex's strategy while
+accelerating hot spatial operations with a Python-integer bitboard engine. Its
+filename, class, and registry key include the model name, while its public
+Battlesnake API name remains `PrismBattleSnake`.
+
+Run it with:
+```sh
+SNAKE=PrismBattleSnake_GPT_5_6_Sol python main.py
+```
+
+Benchmark Apex and Prism against sampled positions from a gameplay database:
+```sh
+python scripts/benchmark_snakes_from_db.py \
+  --database /path/to/gameplay.sqlite3 \
+  --samples 100
+```
+
+The benchmark opens SQLite read-only and reports mean, median, p95, and maximum
+move latency. Increase `--samples` for a broader but slower comparison.
+
+## Compact gameplay database
+New gameplay turns use normalized storage: the turn row stores food, hazards,
+move, and thinking data once; snake identity is stored once per game in
+`game_snakes`; and changing snake state/body data lives in `snake_turns`. Replay
+loading rebuilds the normal Battlesnake board payload.
+
+Create and verify a separate compact copy of an existing SQLite database. By
+default, replay-heavy rows are retained for games rated `medium` or `high` by
+structural completeness, valid moves, thinking coverage, game length, move
+diversity, opponent data, and terminal outcome. All game-result rows remain
+stored, so historical win/loss rates stay persistent when low-quality replay
+data is removed.
+```sh
+python scripts/migrate_gameplay_database.py \
+  --source /path/to/gameplay.sqlite3 \
+  --destination /path/to/gameplay.compact.sqlite3 \
+  --minimum-quality medium
+```
+
+After reviewing the compact copy, `--replace` renames the original to a
+timestamped backup and puts the verified compact database at the original path.
+Stop all writers before using it:
+```sh
+python scripts/migrate_gameplay_database.py \
+  --source /path/to/gameplay.sqlite3 \
+  --replace
+```
+
+The migration never modifies the source in place. It verifies row counts and
+runs SQLite's `integrity_check` before any replacement.
+
+### Record new games while cleanup runs
+Point the running server at a temporary delta database while the old database
+is being compacted. After stopping the writer and flushing the delta database,
+merge it into the cleaned copy:
+```sh
+python scripts/merge_gameplay_databases.py \
+  --base /path/to/gameplay.compact.sqlite3 \
+  --delta /path/to/gameplay.delta.sqlite3 \
+  --destination /path/to/gameplay.merged.sqlite3 \
+  --minimum-quality medium
+```
+
+The merger keeps all game results, quality-rates delta games, regenerates
+numeric turn IDs, and verifies row counts, foreign keys, and database integrity.
+Identical game IDs are skipped; conflicting duplicates abort the merge. After
+reviewing the result, `--replace-base` backs up and replaces the cleaned base.
+Stop the delta writer before the final merge and file swap.
+
 ## Export Training Dataset
 Game saves now include a `dataset` section with labeled move samples.