Drop the single-database split and re-baseline the control migrations

Every deployment has been through the per-blog split, so the code that
performed it (split.go, control migrations 00002–00007) is dead weight, and a
fresh install replaying six migrations only to drop the tables again was
silly. The control chain is now a single 00001_init.sql with the final users
and blogs shape, matching the blog chain.

Goose ignores versions recorded in the database that no longer exist in the
source, but refuses a future migration numbered below the database's highest
version. Databases that went through the split therefore need
`DELETE FROM goose_db_version WHERE version_id > 1` once; README and
AGENTS.md say so.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Sd8UPWrvyYCLj97JexNw3A

1 files changed, 6 insertions, 5 deletions

diff --git a/AGENTS.md b/AGENTS.md
index 8b997e4..4ff23f8 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -47,8 +47,7 @@ cmd/blogspace/        main.go (serve|seed|migrate, superadmin + root blog bootst
                       migrates every blog database at start), seed.go
 internal/config/      env → Config; RootSubdomain = "www"
 internal/db/          Cluster (control pool + lazy per-blog pools, CREATE/DROP DATABASE),
-                      goose providers; migrations/control/*.sql, migrations/blog/*.sql,
-                      split.go (control Go migration 00006: the one-off move to per-blog DBs)
+                      goose providers; migrations/control/*.sql, migrations/blog/*.sql
 internal/store/       Store = control DB (users, blog registry, create/delete blog);
                       BlogStore = one blog's DB (settings, pages, posts, images, sections, modules, menu)
 internal/auth/        bcrypt, JWT issue/parse, cookie, HMAC CSRF
@@ -218,9 +217,11 @@ superadmin password to `admin`. Production refuses both.
   (runs in every blog database — it must not reference `users`/`blogs`) and
   `internal/db/migrations/control/` for users and the registry; goose
   `-- +goose Up/Down` sections; they run automatically at startup. Never
-  edit an applied migration. Control 00005–00007 are the one-off split (add
-  `db_name`, move content in `split.go`, drop the old tables) — a fresh
-  install still replays them.
+  edit an applied migration. Both chains were re-baselined at 00001 after
+  the move to per-blog databases; deployments from before it have
+  `goose_db_version` rows 2–7 in the control DB that must be deleted once
+  (README "Upgrading from a single database") or the next control migration
+  is refused as "missing".
 - Blog content goes through `BlogStore` methods, which take `ctx` first and
   are bound to one blog's database, so a blogger can never touch another
   blog's rows; users and the registry go through `Store`.