Project config file (gonext.yaml) as the root marker and home for CLI-facing settings

Today `internal/project.Root` identifies a generated project by the `go.mod` in the current directory, and that is the only thing the CLI knows about a project beyond its module path. That works while the CLI has nothing project-specific to read, but two things are about to change that.

**Proposal:** `gonext init` writes a `gonext.yaml` (name/format open — `.gonext`, `gonext.toml` are equally fine) at the project root, and `internal/project` gains `Load(root)`. `Root` then looks for that file instead of `go.mod`, so `gonext migrate` in an arbitrary Go module fails with "not a gonext project" rather than materializing a runner that doesn't compile.

**What goes in it** — only keys with a real reader in the CLI, added with the feature that reads them:

- database engine once #71 lands (the runner templates and `docker-compose` orchestration branch on it);
- installed feature packs, for `gonext add` / `gonext doctor`;
- possibly the gonext version that scaffolded the project, for `gonext add` to reason about compatibility.

**Not now:** creating the file with no keys, as a marker only, is not worth a file in every project. The first key and the file arrive together — likely with #71.

**Touch points when it happens:** `cmd/scaffold/init.go` (write it), `internal/project` (`Root` + `Load`), `templates/` (the file itself, since `templates/` mirrors the final tree), `copy_golden_test.go` if any value is per-scaffold.

Related: #71 (first concrete key), #70 (more Make targets becoming subcommands that would read it).

Start with related issue #71, then read cmd/scaffold/init.go and internal/project's Root implementation. Review templates/ and copy_golden_test.go for scaffolded files and values. Done means the chosen project config format arrives with its first real key, init writes it, Load reads it, Root rejects arbitrary Go modules, and relevant tests cover the behavior.

Written by the indexing model from the issue text.