[rosseyre]

Summary

Heavy Tests on master fail at tests/heavy/pg_upgrade_matrix.sh. Building the pre-v0.13 fixture fails with:

ERROR:  cannot drop column origin_page_id of table links because other objects depend on it
DETAIL:  policy ks_source_isolation on table links depends on column origin_page_id of table links

Migration v129 (#53, per-artifact access labels) changed the links RLS policy so it reads origin_page_id. As a result, the down-mutate's ALTER TABLE links DROP COLUMN origin_page_id can't run. run-heavy.sh stops at the first failing script, so the three scripts after the matrix haven't run in CI since then either.

Fix: the pre-v0.13 down-mutate now drops ks_source_isolation ON links before it drops the column. A real pre-v0.13 brain never had this policy, so the fixture is now more accurate. The walk-forward (v11 → v129) adds the column back first and then re-creates the policy. This PR changes the fixture only; no product code changes.

Test plan

Run locally against Postgres 16 + pgvector with Bun 1.3.13:

• Reproduced the exact failure on unmodified master (_build_legacy_fixtures.sh pre-v0.13 exits 3)
• bash tests/heavy/pg_upgrade_matrix.sh: both shapes walk forward cleanly
• After the walk-forward, the links policy exists again and still has its origin_page_id clause
• bun run test:heavy: all 6 scripts pass, including the 3 that had been hidden behind the matrix failure

---

Generated by Claude Code

[rosseyre]

Two red unit shards. Neither is caused by this PR, which only changes tests/heavy/fixtures/down-mutate-pre-v0.13.sql. No unit test loads that file.

• test (5): progress reporter > only one process-level signal handler installed across many reporters (test/progress.test.ts). The same check fails on master: the last three master pushes (v0.43.0.27 fix: local CPU embeddings (llama-server), git-first deletions, takes RLS grants #57, v0.43.0.28 fix(links): wikilinks into any folder, unique basenames by default, extract --stale resolution #59, v0.43.0.28 feat(mcp): serve operator-set server instructions in initialize #58) all report it as already failing. The file passes on its own (17/17) and only fails when it shares a shard with other files. My guess is that module-level reporter or signal state in src/core/progress.ts leaks in from another file, but I haven't checked. No fix exists yet.
• test (4): 10K-page batched delete completes in <5s on PGLite (test/sync-delete-batch.slow.test.ts) hit its 30s timeout after 84s. The whole shard also ran about 13 min, against about 8 min on master. This shard passed on master. Locally the file passes in about 12s with the shard's --timeout=60000. It's a wall-clock perf test that trips on a slow or contended runner. It isn't a regression from this diff.

I'm keeping both fixes out of this PR so it stays scoped to the Heavy Tests fixture. I tried to re-run the failed jobs, but this integration doesn't have permission (403), so a maintainer would need to use "Re-run failed jobs".

---

Generated by Claude Code