fix(db): pin the primary-key plan in the search retirement read-bound test (#8556)

The test disabled only sequential scans, so the planner could still answer a page with a
bitmap scan that reads every remaining row. Which plan it chose depended on whether
autovacuum had analyzed the fresh fixture rows, making the read-count assertion flaky in CI.
Analyze the table and disable bitmap scans too, matching production's primary-key walk.

packages/db/script-migrations/0027_retire_search_embeddings.integration.ts

@@ -415,10 +415,14 @@ describe('retiring dormant Search embeddings', () => {
     await sql`CREATE TRIGGER bound_document_update AFTER UPDATE ON document
       REFERENCING NEW TABLE AS changed_rows FOR EACH STATEMENT EXECUTE FUNCTION bound_document_update()`
     /**
-     * On a table this small the planner may answer any page with a sequential scan, which reads
-     * every row whatever the window; production pages use the primary key, so the test does too.
+     * On a table this small the planner may answer any page with a sequential or bitmap scan, which
+     * reads every remaining row whatever the window, and which one it picks depends on whether
+     * autovacuum has analyzed the fresh rows. Production pages walk the primary key, so the test
+     * analyzes the table and pins that plan.
      */
+    await sql`ANALYZE document`
     await sql`SET enable_seqscan = off`
+    await sql`SET enable_bitmapscan = off`
     /** Document rows read by any scan, counted across committed and rolled-back pages alike. */
     async function documentReads() {
       await sql`SELECT pg_stat_force_next_flush()`
@@ -446,6 +450,7 @@ describe('retiring dormant Search embeddings', () => {
       ).toBe(0)
     } finally {
       await sql`RESET enable_seqscan`
+      await sql`RESET enable_bitmapscan`
       await sql`DROP TRIGGER IF EXISTS bound_document_update ON document`
       await sql`DROP FUNCTION bound_document_update()`
     }