Fix duplicate migration 000036: renumber stashes to 000037

[keyxmakerx]

Requested by Key Maker · project thread

Fixes: none
Security implication: none (migration file renumber only)
Consumer-verified: n/a
Mockup: n/a

What this changes

Before: #969 (000036_campaign_book_edits) and #974 (000036_stashes) both merged with core migration number 36. Main fails TestMigrations_GaplessSequence (full sequence: [... 35 36 36]), and golang-migrate refuses two migrations with one version, so a server built from main would not migrate.

After: the stashes migration is 000037_stashes and ExpectedCoreMigrationVersion is 37. File contents are unchanged.

Why

The two PRs were open at the same time and each took the next free number. Renumbering is safe because neither migration has been applied anywhere (nothing deployed since they merged). Merge this before deploying.

Test plan

• Reproduced on main: go test -short ./internal/database/ fails TestMigrations_GaplessSequence
• With this change: go test -short ./internal/database/ ok
• CHRONICLE_TEST_DB_DSN='root@tcp(127.0.0.1:13306)/' go test ./internal/database/ ./cmd/...: ok (fresh-DB replay in cmd/server included)
• go build ./...
• CI passes

Tenet self-check

• T-B1 security: n/a
• T-B2 plugin isolation: n/a
• T-B3 production UI: n/a
• T-B4 docs: n/a

🤖 Generated with Claude Code

https://claude.ai/code/session_01W8zrackYDNg1g6gV6czVhv

---

Generated by Claude Code

[keyxmakerx]

Build & Test is red on purpose-built grounds: the migration immutability guard. tools/check-migration-immutability.sh fails any PR that deletes a migration file present on main, and renumbering 000036_stashes to 000037_stashes shows up as a delete. The guard has no override.

The guard protects databases that may already have applied the migration. That can't be the case here. Main currently has two migrations numbered 36 (000036_campaign_book_edits from #969 and 000036_stashes from #974). golang-migrate refuses a duplicate version, so no server built from main since those merges can have applied either file.

Options:

1. Merge this PR with the guard check red. It is diff-scoped, so other PRs are unaffected afterwards. This is my recommendation.
2. Add a one-time allowance for this file to the guard. I haven't done that, because it would mean a PR loosening its own safety check without the operator's say-so.

Steps after the guard did not run in CI. Locally, go test -short ./internal/database/ and the fresh-DB replay (go test ./cmd/server against MariaDB) pass with this change and fail on main.

---

Generated by Claude Code