Distribute the runtime as a separately versioned module

Came out of an ideation session, not a scoped request.

Today gonext ships as one module under one version: the CLI a developer installs and the library a generated project imports are the same artifact at the same `vX.Y.Z`. The idea is to carve the runtime surface into its own module with its own tag line — name still undecided, `core` or `lib` — so a generated project's `go.mod` depends only on that small module, and someone can take the runtime without the CLI. `gonext` stays a dev-time-only tool: production remains a plain binary built from the project's own `main`, which links the runtime module, matching the usual Go model where the library does not own `main`.

Note this reverses the single-module decision currently described in `roadmap.md`; whichever piece lands the decision should update that section.

- [ ] Decide the module name (`core` vs `lib`) and set it up as a separately tagged module
- [ ] Move the runtime surface (starting with `auth/`) into it and repoint `templates/` imports
- [ ] Pin the runtime module version into the generated `go.mod` at scaffold time
- [ ] Define the release process and compatibility policy for the two tag lines

Start with roadmap.md to understand the current single-module decision, then inspect auth/, templates/, and the generated go.mod handling. Resolve the module name and define the two tag lines, then move the runtime surface, pin its version in generated projects, and document release and compatibility rules.

Written by the indexing model from the issue text.