Containerize the API with a persistent volume

The API deployable had no packaging of its own: its runtime deps lived
only in the integration's dev group, so there was no way to deploy the
service without dragging the test venv along. Package the API as a
container image (Dockerfile, multi-stage slim build, non-root) with the
deployable's own manifest api/requirements.txt, and run it via
deploy/compose.yaml with the SQLite file on the named volume
nestquest-db so recreating the container keeps household data.
Secrets are supplied by the environment (ignored deploy/.env, example
with placeholder names only). TLS/reverse proxy, Authentik wiring and
network separation are later Feature 17 tasks; the port is bound to
localhost until they land.

api/requirements.txt

@@ -0,0 +1,15 @@
+# Runtime dependency manifest for the NestQuest API deployable.
+#
+# The monorepo's pyproject.toml carries fastapi/uvicorn/pyjwt/httpx in
+# the INTEGRATION's dev group only (so the test venv can exercise the
+# API); they are deliberately NOT integration runtime dependencies.
+# Per that manifest's own comment, the API deployable declares its own
+# runtime dependencies HERE — this file is what the container image
+# installs (see the Dockerfile at the repository root).
+#
+# Compatible ranges mirroring the dev group's floors; the API is a
+# server, so these are the only packages its runtime needs.
+fastapi>=0.115
+uvicorn>=0.30
+pyjwt[crypto]>=2.9
+httpx>=0.28