Docker/deployment tooling is entirely absent: no Dockerfile, no docker-compose for local Postgres, no CI pipeline definition #30

Background

Confirm by listing the repo root: there is no Dockerfile, no
docker-compose.yml, and no CI workflow definition anywhere in this
repository, despite package.json having test, test:cov, test:e2e,
lint, and build scripts that presumably should run automatically on every
PR, and despite the README's "Setup, run, test" section presumably
instructing contributors to run against a local Postgres instance with no
provided way to spin one up consistently (confirm the exact wording of that
section).

Problem Statement

This is an infra/tooling spike with a concrete deliverable. New external
bounty contributors (the exact audience this issue batch is being written
for) need a fast, reliable, reproducible way to: (1) get a local Postgres
instance matching production's version/config, (2) run migrations (once the
migration-tooling issue lands) against it, (3) run the full test suite
including test:e2e which presumably needs a real database, and (4) have
confidence their PR passes the same checks CI will run — none of which is
currently possible without significant tribal knowledge or manual setup.

Requirements

• Add a multi-stage Dockerfile that builds and runs the NestJS app for
  production (small final image, non-root user, proper NODE_ENV=production
  handling, respecting the INSECURE_DEFAULT_JWT_SECRET production guard
  already in main.ts).
• Add a docker-compose.yml for local development: the app service plus a
  Postgres service with a version matching whatever pg driver
  compatibility implies, wired to .env/.env.example conventions, with a
  documented one-liner startup command in README.md.
• Add a CI pipeline definition (a GitHub Actions workflow file) that on
  every PR: installs dependencies, runs lint, runs build, runs test and
  test:cov (against an ephemeral Postgres service container in the
  workflow), and runs test:e2e if it's runnable without external secrets
  (guard/skip cleanly if it requires real GitHub OAuth/Soroban credentials
  that can't exist in CI — document this limitation rather than leaving a
  failing/flaky job).
• Ensure secrets (JWT_SECRET, GITHUB_WEBHOOK_SECRET, etc.) are never
  baked into the image or committed — use build args / runtime env only, and
  add a basic secret-scanning step to the CI workflow (or document why it's
  deferred) given how many env vars in .env.example are financial/security
  sensitive (TREASURY_SECRET, GITHUB_CLIENT_SECRET).
• Update README.md's "Setup, run, test" section to reflect the new
  Docker/CI-based workflow as the primary recommended path.

Acceptance Criteria

• Starting the stack via the new compose file from a clean checkout
  results in a working API reachable at the configured port, backed by
  a fresh Postgres instance.
• The production Dockerfile produces a working, reasonably minimal
  image that correctly refuses to start with an insecure default JWT
  secret in production mode (matching main.ts's existing guard).
• A CI workflow runs lint/build/test/test:cov against a real ephemeral
  Postgres service on every PR and reports pass/fail clearly.
• README updated with the new setup instructions, verified to actually
  work by following them from scratch.

Technical Notes

Files to add: Dockerfile, docker-compose.yml, a GitHub Actions workflow
file, and a .dockerignore. Reference src/main.ts for the production JWT
guard behavior that the Docker image must respect, and .env.example for
the full set of required/optional environment variables the compose file
needs to wire up.

Difficulty Justification

This is a spike requiring judgment calls across several domains at once
(container image security/minimization, CI service-container orchestration
for a stateful Postgres dependency, secret-handling hygiene for an
unusually sensitive .env surface, and making the existing partially-testable
suite actually runnable headlessly) rather than copying a generic Node
Dockerfile template — done carelessly it would introduce new security holes
in exactly the areas (secrets, production guards) the rest of this issue
batch is trying to harden.