Environment management: how dev, test, stg and prod configuration is expressed

Configuration for a generated project is currently spread across three places that grew independently:

- `.env` (copied from `.env.example` by `gonext init`), loaded by `gonext dev` / `gonext migrate` / `gonext openapi` (#73). Holds `ENV`, `PORT`, `LOG_*`, `SHUTDOWN_TIMEOUT`, `DATABASE_URL`, `TEST_DATABASE_URL`.
- `Makefile` defaults — `ENV ?= dev`, `PORT ?= 8080`, `TEST_DATABASE_URL ?= …` — used by `test` and `smoke`. `DATABASE_URL` was removed from here in #73; the other three were deliberately left until this issue decides their fate.
- `backend/internal/config.Config`, which reads real environment variables and validates them (`ENV` is `oneof=dev test stg prod`), and is what a deployment actually feeds.

`roadmap.md` lists *Configuration* as "Typed Config + `mise`, centralized type-safe environment configuration with `.env.example` validation", and `.env.example` still mentions `mise.local.toml` as the override mechanism — neither matches what exists.

**Decide and implement one model.** Questions the design has to answer:

- One `.env` with `ENV=dev`, or per-environment files (`.env.test`, `.env.stg`…)? How does `make test` get `TEST_DATABASE_URL` — its own file, a `TEST_` prefix convention, or the same `DATABASE_URL` under `ENV=test`?
- What is the precedence: shell > `.env.` > `.env` > `config` defaults? (Today: shell > `.env`; the Makefile sits outside that chain.)
- Does `mise` play any role (`mise.local.toml`, `[env]` sections), or is that mention just stale?
- Which of these does the server binary read in production — presumably none; it gets real env vars. The docs should say so explicitly.
- Validation of `.env.example` against `config.Config` (every field documented, no stale keys) — a test in the generated project, or a `gonext doctor` check?
- Whether the `docker-compose.yml` credentials (`app`/`app`) are duplicated in `.env.example`, `initdb/create-test-db.sql` and the `pg_isready` calls should come from one place.

**Outcome:** a spec, then: the three Makefile variables either move into the chosen files or are justified where they are; `.env.example` and `roadmap.md`'s Configuration row rewritten to describe the real model; `project.LoadEnv` extended if per-environment files are chosen.

Related: #73 (introduced `.env` loading), #72 (`gonext.yaml` — project-level config the CLI reads, distinct from runtime env), #71 (database choice will add keys).

Compare backend/internal/config.Config, project.LoadEnv, the Makefile, .env.example, roadmap.md, docker-compose.yml, and initdb/create-test-db.sql to map the current configuration paths. Define the chosen precedence, environment-file model, validation, and credential source before implementing it. Done means the spec is reflected in the generated project, documentation, Makefile behavior, and relevant validation or checks.

Written by the indexing model from the issue text.