fix(storage): bump SCHEMA_VERSION so pre-#305 indexes get the valid-time columns

[mavaali]

Summary

An index built before #305 cannot be opened after upgrading past it. The vault refuses to serve with:

cannot open index db: no such column: valid_from

#305 added valid_from/valid_until to the documents DDL and to the upsert, but left SCHEMA_VERSION at "10" — the value #303 had already introduced — while editing the comment above it to claim the bump covered them. CREATE TABLE IF NOT EXISTS is a no-op against an existing table, so any index built between #303 and #305 stored version 10 without the columns, matched on the version check, skipped the rebuild, and died on its first upsert.

Recovery today is manual: delete .daftari/index.db. That works — the index is ephemeral by design — but the failure is a hard error with a cryptic message rather than the automatic rebuild SCHEMA_VERSION exists to trigger.

CI cannot catch this class of bug. index.db is gitignored, so every CI run builds a fresh index and never reaches the upgrade path. It only appears when upgrading in place. It surfaced here from a stale local database and reproduced on three separate ones — the sample-vault fixture and both packages/router fixtures, all reporting schema_version: 10 with no valid_from.

Why a bump rather than an ALTER

The bump is cheap now, and #305 is the reason. That same commit removed embeddings from the drop list, on the grounds that it is content-addressed on (content_hash, model, dim) and so cannot be invalidated by a documents column change — test/storage/schema-bump-embeddings.test.ts pins it. A version change therefore rebuilds derived tables from the markdown and leaves the durable vector cache intact; embeddings_vec is a mirror, repopulated at zero provider cost.

So the expensive part of a bump was removed in the same commit that needed one. An idempotent ALTER TABLE migration would be strictly more code for a cost that no longer exists.

Test plan

test/storage/schema-valid-from-migration.test.ts constructs the stale state explicitly — writing a documents table exactly as it stood before #305 plus a schema_version of 10 — because that is the only way to cover a path a fresh checkout cannot reach. Four cases:

• the database opens instead of returning no such column: valid_from
• it gains both valid-time columns
• the freshness manifest is cleared, so the rebuilt tables actually repopulate rather than existing empty
• the new version is recorded, so the rebuild runs once and not on every open

Two existing assertions in test/storage/index-db.test.ts that hardcoded "10" are updated to "11".

• npm run lint — pass
• npm run build — pass (tsc, clean)
• test/storage/ — 93/93 pass
• New behavior has tests — yes, the migration test above

Invariants

Touches only the SQLite index, which CLAUDE.md declares ephemeral and rebuildable from the markdown at any time — this change restores that property for the upgrade path rather than bending it. No frontmatter, no new metadata format, no versioning mechanism, no src/tools/ handler.

Note on origin

Found while working on #306 (read-path fence) and originally committed there. Split out at the repo owner's request so it can merge independently — users upgrading past #305 stay broken until it lands, and that shouldn't wait on unrelated design work. #306 no longer carries it.

---

Generated by Claude Code