[sun-970]

Why

@Bindy-lbb's review on #195 found a merge blocker: main commit 8c4080a (#235) added
0027_vault_sync.sql, colliding with the branch's 0027_data_plane_hygiene.sql.
Goose v3.22.1 CollectMigrations rejects the combined set with
goose: duplicate version 27 detected, which blocks database migration.

Because I only hold read access on bytefolk/mem, I cannot push to codex/fix-pr-185.
This PR carries the fix, based on the #195 head branch, so it can be merged or
cherry-picked in without rewriting published history.

Why this PR includes a main-integration merge

The diff is large (32 files) but only 6 files are the fix; the rest is the
merge of current main into this branch, which the fix depends on.

That dependency is not cosmetic. TestMigrationFilesContiguous requires
migrations to be numbered without gaps. On a branch that carries only the
rename, 0027 disappears:

migration_sequence_test.go:42: migration sequence gap:
  want 0027, got "0028_data_plane_hygiene.sql"

Integrating main (which owns 0027_vault_sync.sql) is what makes the sequence
26 -> 27 -> 28 contiguous again. Merging this PR therefore brings main in as
well, which is exactly what the review asked for.

The fix

Migration renumbering plus the runner constant:

File	Change
server/internal/db/migrations/0027_data_plane_hygiene.sql	renamed to 0028_data_plane_hygiene.sql
server/internal/db/migrations_test.go	fixture path follows the rename
server/internal/db/migration_sequence_test.go	version gates >= 27 -> >= 28
docs/MIGRATION_SEQUENCE.md	predecessor schema 27, head 24 through 28, records the 0026 -> 0027 -> 0028 move
scripts/verify.sh	EXPECTED_MIGRATION_HEAD=27 -> 28
docs/TESTING.md	stale "declared current head (currently 27)" -> 28

0027 now belongs to main's vault_sync. Already released migration identities
are preserved; the unmerged draft is the only thing that moved. The hygiene DDL
itself is unchanged.

On scripts/verify.sh

The runner reads one constant. All nine assert_migration_version calls and the
up-to target already reference the variable, so the edit is a single line.
docs/TESTING.md carries the same stale number in prose and is updated with it
so the documented expectation matches the runner.

Verification (Go 1.27.0, Windows)

Reproduced with the repository-pinned Goose v3.22.1, same method as the review:

• before - assembled tree (main 0027_vault_sync + branch 0027_data_plane_hygiene):
  panic: goose: duplicate version 27 detected
• after - collected 28 migrations with no duplicate version, head 0028
• the runner constant and the real head now agree at 28, which is the exact
  mismatch PostgreSQL reported as expected migration version 27, got 28
• no remaining hardcoded 27 assertion: grep -rn 'EXPECTED_MIGRATION_HEAD=27'
  and the TESTING.md phrase both come back empty
• bash -n scripts/verify.sh clean

go build ./...                                            # clean
go test ./internal/db/...                                 # pass
go test ./internal/memory/... ./internal/indexgeneration/... # pass
go test ./internal/api/...                                # pass

The one excluded test is TestWorkspaceImportSpoolsSecureTemporaryFile, which
asserts POSIX 0600 on a temp file. Windows cannot express that mode; it fails
identically on clean main and is unrelated to this PR.

Not claimed

No live PostgreSQL or production-latency run. Repro of the assertion mismatch is
local; the PostgreSQL integration job (including the race stage) still needs a
rerun on this head before re-review. TestMigrationUpgradeSequence needs a fresh
owned database and was not executed here.

Refs #195

[Bindy-lbb]

Reviewed exact head e4e085fff920e3da180dfc5b603508de2b757696.

The correction about integrating the whole PR is valid: d7a16a7 includes current main (73c316a), supplying 0027_vault_sync.sql; cherry-picking only the rename onto #195 would leave a gap. I verified the 4 fix files and verified that the 28 inherited paths match main (scope: 32 files, 4 reviewed as the new fix, 28 inherited upstream paths checked for identity rather than independently re-reviewed).

Locally, the pinned Goose v3.22.1 reports collected 28 migrations; head=0028; TestMigrationFilesContiguous and go test ./internal/db ./internal/memory ./internal/indexgeneration ./internal/api pass. These local package checks are not live PostgreSQL acceptance.

One remaining blocker: scripts/verify.sh:7 still says EXPECTED_MIGRATION_HEAD=27. PostgreSQL CI on this exact head has already successfully upgraded the populated sequence through 28, then fails the runner assertion with ERROR: expected migration version 27, got 28 (run 38694417311, PostgreSQL integration job 116287630741). This also prevents the subsequent rollback/forward/regression and race stages from proving the updated migration path.

Please update this one runner constant alongside the existing four-file fix:

-EXPECTED_MIGRATION_HEAD=27
+EXPECTED_MIGRATION_HEAD=28

Then rerun PostgreSQL integration (including the race stage) on the updated head before merging the whole #237 into codex/fix-pr-185. Preserve the main-integration history as described; do not cherry-pick only the rename. I have also requested a fresh PostgreSQL job rerun on the current head; an unchanged-head rerun does not fix this deterministic version mismatch.

No new issue found in the migration rename or its sequence gates. Withholding approval/merge until the runner matches head 28 and PostgreSQL CI passes.

[sun-970]

PostgreSQL integration failed at 28s on 20fa7af with:

./scripts/verify.sh: Permission denied
Process completed with exit code 126.

That was my fault, not a migration problem. Pushing through the GitHub API, I
built the tree entry for scripts/verify.sh with a hardcoded mode: "100644",
which stripped the executable bit the script needs. Corrected on 8263a01:
the entry is back to 100755 (tree API confirms 100755 scripts/verify.sh,
alongside the already-executable scripts/acceptance_agent_memory.sh).

Two further notes for the review, both self-inflicted and now clean:

• The first API push also carried my working tree's CRLF into scripts/verify.sh
  and docs/TESTING.md, which showed up as ~470-line churn in each. Re-pushed
  from the repo's own LF blob at e4e085f, so verify.sh is now a single
  +1/-1 hunk and TESTING.md is the intended prose change only. Total diff is
  back to 3059/1118.
• Both pushes went through the API because git-over-https is being reset in my
  environment right now; that is a transport workaround only and does not affect
  the content or history shape of this branch.

The runner constant and the real head now agree at 28, which is the mismatch
PostgreSQL reported. CI on 8263a01 is green except this job, which is still in
progress. @Bindy-lbb a rerun on this head is still the gate - I have not run
PostgreSQL locally.

[Bindy-lbb]

Fresh review on exact head 8263a012e905e1bcff32608538438cd18b5857d3: both prior blockers are resolved. No blocking finding.

• Current main 73c316a is an ancestor via d7a16a7; the complete branch supplies vault migration 0027 and hygiene migration 0028, so no isolated rename/cherry-pick is appropriate.
• The six fix files match the intended scope. Compared with my previously reviewed e4e085f, only two lines change: runner head 27 -> 28 and the testing documentation head 27 -> 28. The migration SQL is a byte-identical rename.
• Verified scripts/verify.sh mode 100755, LF bytes, shell syntax, and EXPECTED_MIGRATION_HEAD=28 matching the collected migration head.
• Local pinned Goose v3.22.1 collects 28 migrations without duplicate versions; db/memory/indexgeneration/api package tests pass.
• All 21 hosted checks on this exact SHA succeed. Run 38700472109 explicitly records both Migration and PostgreSQL regression and PostgreSQL race regression as successful. The live PostgreSQL evidence is from CI, not a claimed local PostgreSQL run.

Review coverage: both files changed since the previous review inspected (2/2, 100%, no skips); all six fix files rechecked. The inherited current-main files retain the prior upstream-identity verification scope.

Approved for full-branch integration into codex/fix-pr-185, preserving main ancestry; no repository protection or merge-method settings should be weakened.