Reconcile Dockerfile & compose for dev/prod targets

[mbarlow12]

Motivation

This is mainly to address the action failure in #2. There's layered caching in the Dockerfile with dev and prod targets. This allows us to leverage the develop spec for local development while maintaining nearly exact parity between "prod" and "dev" environment, the main difference being that "prod" won't have the uv artifacts (/uv, /uvx, /bin, /root/.cache/uv) and sets up a non-root user to actually run uvicorn.

Summary

• Rewrite Dockerfile to 3 stages (base → dev → prod), eliminating the separate builder stage
• Switch base images from Debian trixie to bookworm (stable)
• Add UV_NO_DEV=1 and UV_PYTHON_DOWNLOADS=0 for leaner, portable builds
• Prod stage copies venv from dev instead of building/installing wheels via pip
• Replace volumes: .:/app bind mounts with develop.watch (sync + rebuild rules)
• Add --reload via compose command: override (Dockerfile keeps prod-safe default)
• Delete Dockerfile.api prototype (merged into main Dockerfile)
• Add Make Targets section to README documenting all make shortcuts

Test plan

• docker compose build — dev target builds successfully
• docker compose up --watch — API starts, db-init completes
• Edit a .py file in deployments/api/src → uvicorn reloads
• Edit pyproject.toml or uv.lock → image rebuilds
• docker build --target prod -f deployments/api/Dockerfile -t stitch-api:prod . — prod builds
• docker run --rm stitch-api:prod whoami → nonroot

[AlexAxthelm]

I'm on board with some of the changes, but this seems like a pretty big shift. In general, I'm comfortable with a two-layer build/run paradigm, but in this case, I'm not really sold on the need for a separate dev target.

Given that we support local dev, and that python is pretty happy with working from a volume mount, I think the dev experience would be better keeping the two-layer we have (some of these changes, like non-root user, come through), and triggering a manual rebuild if we need to alter our dependencies (the message being that we should be touching the lockfile infrequently)

[mbarlow12]

@AlexAxthelm here's the latest summary:

• volume mounts w/ local compose yml split (keeps things simple) + minimal watch to support automatic rebuilds + sync
  • volume mounts don't include .venv
  • use uvicorn reload options to exclude restarts on test changes
  • uv sync makes editable installs by default, the .venv holds minimal path references to the appropriate directory for imports, so changes to mounted directories don't require uv sync to take effect
• 2 stage build with cached 3rd party deps & slightly wider COPY
  • We may include some packages that aren't used by stitch-api but they won't appear in the .venv
  • Retains ~30mb of the copied uv files (I'd vote worth it for the dependency caching) if we don't want that, we're in 3-stage build land