A rebuild that could not rebuild past a schema change

[MongLong0214]

Fixes #774.

rebuildIndex clears rows and keeps the tables, and its DELETE FROM meta deliberately preserves schema_version — so on a database written by an older release the stale state survives its own repair. The first insert then dies on a column the table does not have.

Measured

A worktree whose index came from v1.0.2:

trailers columns named signature_status    0
commitlore index --rebuild                 NOT NULL constraint failed: trailers.signature_status

A constraint on a column that does not exist. Deleting the file made the identical command succeed; restoring it made it fail again. Twice each.

The same database later reported table trailers has no column named signature_status — two SQLite symptoms of one cause, and the first is the more misleading.

The condition was already handled, one branch over

healthProblem returns "index was built by schema v3, this build expects v4", and ensureIndex resets the file on it. The command named rebuild was the one path that did not, because index-cmd.ts opens the index and calls rebuildIndex directly rather than going through that branch.

So the reset belongs to the rebuild, not to one of its callers.

I fixed the force branch of ensureIndex first. It changed nothing — --rebuild never reaches it. That is the second time today a first fix landed on a path that does not fire; the other was the empty-payload return in inject.ts (#778).

What this corrects on the issue

The reproduction I originally filed — "a worktree detached a few hundred commits back" — does not reproduce. A fresh worktree at the same old commit rebuilds cleanly. The notes-outside-the-range correlation was real and coincidental. The actual trigger is an index written by an older schema, which is every repository a user upgrades.

Verified

Against the real v1.0.2 database: fails before, rebuilds 652 commits after.

The test writes that schema itself rather than depending on the artefact, so it keeps testing once every such file is gone. A first version of it omitted id INTEGER PRIMARY KEY and failed on no such column: id — a fixture defect wearing the costume of the bug, caught because the error was the wrong one.

75 tests pass across the index and init suites; artifact:verify passes against the regenerated manifest.

Still open on #774

The message. It names a SQLite column rather than the situation, and advises commitlore init — which runs the command that was failing. Both are the shape #746 fixed elsewhere, and neither is addressed here.

Limit (on the commit): this recreates the file whenever the recorded version differs, so a downgrade discards an index a newer build wrote rather than reading what it can from it.

[github-actions]

CommitLore — record lint

Trailers: clean — 2 commits in origin/main..059cc1053a9e36089225ec223420e1711032a2d9
Active constraints: not read — commitlore: git log --follow accepts exactly one pathspec, so renames are not followed for 6 paths; query one path at a time to follow its rename chain (6 changed paths)

_{Trailer violations fail this check. Active constraints are informational — they are what the repository already decided, not a verdict on this PR.}