feat(cli): top-level goten init + plugin registry

[dnahilman]

Closes #25.

Summary

Adds goten init — top-level CLI subcommand that bootstraps a project's migrations from embedded SQL files for core + any plugins declared in goten.config.yaml. Inspired by npx @better-auth/cli generate.

# In a brand-new project, no goten.config.yaml needed yet:
goten init                      # writes ./migrations/*.sql from embed
goten migrate up                # apply to DB

# After adding a plugin later:
go get github.com/dnahilman/goten/plugins/username
# edit goten.config.yaml: migrations.plugins: [username]
goten init                      # core skipped (identical); username files written
goten migrate up                # applies new plugin migrations

Why

Until now, a new project had to git clone the goten repo or curl the raw migration files off GitHub. goten init removes that friction and is idempotent — re-running after adding a plugin only writes the new files.

Design notes

• Plugin registry is a hardcoded map in cmd/goten/registry.go. Compile-time list of official plugins (currently just username). 3rd-party plugins are explicitly out of scope; unknown names error with the available list.
• migrations.plugins: accepts both forms — shorthand - username (new) auto-resolves to ./plugins/username/migrations; full path - ./plugins/username/migrations (existing) still works. Auto-detected by resolvePluginEntry based on presence of / or \. This is shared by both init and the existing discovery walker, so migrate up/down/status benefits too.
• Idempotent semantics: identical destination → silently skipped; divergent → error mentioning --force; missing → written. Per-section summary printed.
• Best-effort config load: missing goten.config.yaml falls back to a synthetic default (./migrations/, no plugins) so init works as the very first step in a new project.

Steps (matching #25's checklist)

• 1.1 Expose goten.CoreMigrationsFS via //go:embed
• 1.2 Export usernameplugin.MigrationsFS
• 1.3 Plugin registry in cmd/goten/registry.go
• 1.4 resolvePluginEntry shared between init and discovery.go
• 1.5 runInit / cmdInit with --force flag
• 1.6 Top-level subcommand wired in cmd/goten/main.go
• 1.7 Tests in cmd/goten/init_test.go (8 cases + resolver table-driven)
• 1.8 CHANGELOG entry

Test plan

• go test ./cmd/goten/... — all green; 9 new tests:
  • TestRunInit_CoreOnly_FreshProject — fresh dir, no plugins, core files appear with embed-identical content.
  • TestRunInit_CoreAndUsername_Shorthand — plugins: [username] shorthand resolves correctly.
  • TestRunInit_CoreAndUsername_FullPath — backwards-compat with explicit path.
  • TestRunInit_Idempotent — second run reports "0 written".
  • TestRunInit_ConflictWithoutForce — pre-existing different content errors and mentions --force; original file untouched.
  • TestRunInit_ConflictWithForce — --force overwrites to match embed.
  • TestRunInit_UnknownPlugin — error names the unknown plugin AND lists available plugins.
  • TestRunInit_NoConfigFile_FreshBootstrap — works with no config file at all (synthetic default).
  • TestResolvePluginEntry — table-driven test of the shorthand/path resolver.
• make build — all six modules compile.
• Manual smoke: bootstrap from mktemp -d, run init, check files; re-run, output says "0 written, 2 skipped".

🤖 Generated with Claude Code