Feat/0.1 hardening

[QuentinHourdeaux]

Summary

Closes out v0.1 hardening with fixes discovered during acceptance testing, a repeatable post-clone setup workflow, and documentation that reflects the shipped v0.1 scope.

• Docker bind mounts: Add a startup entrypoint that adapts the container process to the host-owned /data directory on native Linux, while retaining Docker Desktop compatibility.
• Post-clone setup: Add ./scripts/setup.sh (also available as deno task setup) to prepare data/dev and data/prod, configure tracked Git hooks, install or build locked dependencies, migrate available development and production databases, and report each workflow as ready or blocked.
• Safe database initialization: Run ordered, idempotent migrations only. Setup never resets or replaces an existing database, refuses root execution, and will not open the production database from a second container while the Compose service is running, paused, or restarting.
• Runtime regression coverage: Require both setup workflows to initialize successfully and become current on rerun in CI, then start the production image with a fresh host bind mount and assert that the container becomes healthy and creates a runner-owned, writable SQLite database.
• Draft quick capture: Reject whitespace-only titles with inline validation (Title is required.), focus return, and aria-invalid.
• State settings copy: Clarify that Draft states apply to both standalone Drafts and Drafts in a Stack.
• Docs: Document setup, explicit and startup production migrations, backup/restore, and the completed v0.1 product scope; remove the completed hardening plan.

Root cause and impact

A successful image build did not exercise the production entrypoint against a real host-owned bind mount. On native Linux, a UID/GID mismatch between the image user and ./data/prod could therefore leave the app unable to create or write SQLite even while CI remained green. The entrypoint now handles that boundary at runtime, and CI exercises the same startup, health, and ownership path used by Compose deployments.

For a new clone, users now run one setup command and receive separate Docker and local-development readiness results. Missing Docker does not prevent a valid Deno setup, and missing Deno does not prevent a valid Docker setup. CI separately requires both workflows so partial readiness cannot hide a regression.

Validation

• deno task ci — 291 API tests and 94 frontend tests passed, plus lint, type-check, full API QA, and production build
• Setup initializes both databases in an isolated clone and reports them as CURRENT on rerun
• Representative marker records survive repeated development and production migrations
• Setup blocks a second production migration while the Compose service is running, paused, or restarting
• Setup refuses root execution before modifying the checkout
• Docker Desktop runtime smoke reaches healthy status and creates a user-owned, writable SQLite database on the bind mount
• GitHub Actions Linux setup assertions and runtime smoke pass for the latest commits
• Stop-and-copy backup restore into a fresh checkout follows the documented README procedure