Prep mission expansion: add ENGINE_DEPLOYMENT seam, docs, and copy hooks (Memory default)

[bseverns]

Motivation

• Open the repo’s mission surface so future sibling deployments (question, prompt, repair, witness, oracle) can live on the same local-first engine while preserving Memory Engine as the canonical default.
• Create small, inspectable seams (config, copy, operator labels, and docs) so policy/copy/behavior can diverge later without rewriting routes or operator flows.
• Keep runtime and operator posture intact and local-first, while making responsiveness and playback policy explicit design concerns.

Description

• Add a lightweight deployment catalog and helpers in api/memory_engine/deployments.py with memory as the default and planned sibling codes.
• Make ENGINE_DEPLOYMENT a first-class runtime setting in api/memory_engine/settings.py, document it in .env.example, and validate it in api/memory_engine/config_validation.py so unknown values fail clearly.
• Thread active deployment metadata into surface config and operator payloads by adding deployment info to room_surface_config() in api/engine/views.py and to /api/v1/node/status in api/engine/api_views.py, and surface the active deployment label in the ops HTML template.
• Add a small deployment-aware copy seam to the kiosk runtime by extending kiosk-copy.js with getDeploymentPack and deployment overrides and switching kiosk.js to use the deployment-aware pack so Memory copy remains default while question/repair placeholders exist.
• Centralize and add first-pass docs: docs/MISSION_EXPANSION.md, docs/DEPLOYMENT_BEHAVIORS.md, and docs/RESPONSIVENESS.md, and update README.md, docs/roadmap.md, and docs/maintenance.md to reflect the opening (explicitly stating this is an expansion, not a rebrand).
• Prepare tests and test scaffolding: add frontend tests for kiosk-copy (frontend-tests/kiosk-copy.test.js), update frontend-tests/operator-dashboard.test.js, and extend api/engine/tests/test_config.py and api/engine/tests/test_ops.py to assert deployment catalog and node-status deployment payload behavior.

Testing

• Ran npm run test:frontend (node-based frontend tests) and all frontend tests passed.
• Ran Python syntax/compile checks (python -m py_compile on modified modules) and they succeeded.
• Executed a direct validate_runtime_settings(...) smoke check (local script invocation) to verify deployment catalog + runtime shape and it passed.
• Attempted to run the full Django DB-backed test suite in this environment, but it could not complete because the ephemeral environment lacked the required database connection/envs (test DB name resolved to None); DB-backed tests therefore were not executed here.
• Summary: static checks, frontend tests, and config validation passed; full server-side Django tests require a proper DB/test environment to run and are expected to succeed given the conservative, backward-compatible changes made.

---

Codex Task