Add optional PostgreSQL backend alongside SQLite

## What problem does this solve?

The data layer is SQLite via `modernc.org/sqlite`, deliberately chosen for zero-config simplicity (per the README/tech-stack table). That's the right default, but it's a hard ceiling for anyone who outgrows a single embedded file — no read replicas, no straightforward multi-instance deployment, no built-in point-in-time recovery.

## Proposed solution

- Since `internal/repository` already goes through plain `database/sql` with a `Querier` interface (per the README's description of the pattern), add a Postgres driver behind a `DB_DRIVER=sqlite|postgres` config switch, with connection setup in `internal/config`/`cmd/api` branching on the driver.
- Port the existing SQL to be dialect-agnostic where it's not already (mainly placeholder syntax `?` vs `$1`, and any SQLite-specific pragmas), keeping SQLite as the default so nothing changes for existing users.
- Add a Postgres service to `docker-compose.yml` (opt-in profile) and CI matrix coverage for both drivers so regressions in either backend get caught.

## Alternatives considered

Telling larger deployments to just use SQLite over a network filesystem, or forking to a Postgres-only variant — the first is a known-bad practice (SQLite is explicit that it doesn't support network filesystems safely), and the second duplicates the entire codebase instead of adding one config switch.

## Area

Other

## Priority

Would significantly improve production scalability options while keeping the current zero-config SQLite experience as the default for local/dev use.