Database choice at scaffold time (Postgres / MySQL / SQLite)

Today every generated project is Postgres-only, hardcoded at several layers. Let `gonext init` (and later `gonext add`) offer a database choice, with Postgres staying the default.

**No driver work is needed.** Bun ships dialects for Postgres, MySQL, SQLite and MSSQL, and each has a mature `database/sql` driver (`pgx`, `go-sql-driver/mysql`, `modernc.org/sqlite` — cgo-free). The work is entirely in the generated project's own seams, which are today Postgres-shaped:

- `internal/database/database.go` — `pgxpool` + `pgdialect` in `Connect`; `offline.go` also pins `pgdialect` for the spec injector (harmless, but should follow the chosen dialect).
- `internal/database/postgres_helpers.go` — `IsUniqueViolation` inspects `pgconn.PgError` codes; MySQL/SQLite report unique violations differently.
- `internal/database/migrations/` — hand-written SQL (`RETURNING`, `ON CONFLICT`, uuid/timestamp types, `citext` if used) is not portable across the three.
- `/internal/infrastructure/postgres/` in `example/` and `users/` — package name and any dialect-specific SQL in the repositories, session issuer and token repository.
- `docker-compose.yml`, `Makefile` (`db-up`, `test`, `smoke` all assume a Postgres container and `pg_isready`), `.env.example` `DATABASE_URL`, and `gonext migrate` / `internal/migrate`'s DSN handling. SQLite needs no container at all, which changes the whole `make test`/`make smoke` shape (see #70).
- `dbtest` / testcontainers setup for integration tests.
- README/roadmap feature-pack text that says "Postgres" (River background jobs is Postgres-native and would need to be gated on the choice).

Open questions to settle in a spec before any code:
- Is this a scaffold-time switch that *renames* the infrastructure package and picks one SQL flavour per migration, or does the template keep dialect-neutral Bun query-builder code and only swap `Connect` + the helpers? The second is far less template surface but constrains how migrations are written.
- How does the templates/ ↔ golden/ drift guarantee work with a choice — one golden per option, or golden stays Postgres and the other variants are covered by the e2e test only?
- Does this belong in Core Foundations (every project picks one) or as a feature pack in README's table alongside the existing Postgres-only rows?

Related: #70 (Makefile targets → CLI commands; the Docker orchestration for `test`/`smoke` is the part a non-Postgres choice invalidates).

Start by reading internal/database/database.go, postgres_helpers.go, the migrations, and the templates’ golden and integration-test setup; then review #70 because it affects test and smoke orchestration. Before coding, settle the listed scaffold, migration, package, golden, and feature-pack questions in a spec; done means init/add, migrate, tests, documentation, and generated projects consistently support the chosen database with Postgres still the default.

Written by the indexing model from the issue text.