test(knowledge): pin the schedule rewrite's repair of already-stored rows

Scope the column-precision query to the test schema. It matched on table name
alone, so in CI — where the database already holds the migrated public table —
it saw four columns instead of two and failed. A local run passed because the
throwaway schema was the only place that table existed.

Write the sub-millisecond schedule before applying the migration rather than
after, so the test pins the rewrite rounding an already-wedged row, not just the
narrowed column refusing new ones. Without the migration it now fails on exactly
that claim.

Author: waleedlatif1

packages/db/scripts/connector-sync-schedule-precision.postgres.test.ts

@@ -4,6 +4,7 @@ import {
   migrationTestDatabaseUrl,
   withMigrationSchema,
 } from '@sim/db/scripts/migration-fixture'
+import type postgres from 'postgres'
 import { describe, expect, it } from 'vitest'
 
 const migration = readFileSync(
@@ -18,29 +19,42 @@ const migration = readFileSync(
  */
 const SUB_MILLISECOND = '2026-09-16 17:15:28.261433'
 
+function insertSchedule(sql: postgres.Sql, id: string): Promise<unknown> {
+  return sql.unsafe(`INSERT INTO knowledge_connector (id, next_member_sync_at, next_sync_at)
+    VALUES ('${id}', TIMESTAMP '${SUB_MILLISECOND}', TIMESTAMP '${SUB_MILLISECOND}')`)
+}
+
+/** The sub-millisecond remainder of each schedule, which a `Date` round trip cannot carry. */
+async function subMillisecondsOf(sql: postgres.Sql, id: string): Promise<number[]> {
+  const [row] = await sql<{ member: number; content: number }[]>`
+    SELECT EXTRACT(microseconds FROM next_member_sync_at)::int % 1000 AS member,
+           EXTRACT(microseconds FROM next_sync_at)::int % 1000 AS content
+    FROM knowledge_connector WHERE id = ${id}`
+  return [row.member, row.content]
+}
+
 describe.skipIf(!migrationTestDatabaseUrl)('connector sync schedule precision', () => {
-  it('discards sub-millisecond precision a SQL writer would otherwise store', async () => {
+  it('rounds schedules a SQL writer stored, and refuses to store new ones', async () => {
     await withMigrationSchema('sync_precision', async (sql) => {
       await sql`CREATE TABLE knowledge_connector (
         id text PRIMARY KEY,
         next_member_sync_at timestamp,
         next_sync_at timestamp
       )`
+      await insertSchedule(sql, 'wedged')
+      expect(await subMillisecondsOf(sql, 'wedged')).toEqual([433, 433])
+
       await applyMigration(sql, migration)
       await applyMigration(sql, migration)
 
-      await sql.unsafe(`INSERT INTO knowledge_connector (id, next_member_sync_at, next_sync_at)
-        VALUES ('c1', TIMESTAMP '${SUB_MILLISECOND}', TIMESTAMP '${SUB_MILLISECOND}')`)
-
-      const [stored] = await sql<{ member_sub_ms: number; content_sub_ms: number }[]>`
-        SELECT EXTRACT(microseconds FROM next_member_sync_at)::int % 1000 AS member_sub_ms,
-               EXTRACT(microseconds FROM next_sync_at)::int % 1000 AS content_sub_ms
-        FROM knowledge_connector WHERE id = 'c1'`
-      expect([stored.member_sub_ms, stored.content_sub_ms]).toEqual([0, 0])
+      expect(await subMillisecondsOf(sql, 'wedged')).toEqual([0, 0])
+      await insertSchedule(sql, 'fresh')
+      expect(await subMillisecondsOf(sql, 'fresh')).toEqual([0, 0])
 
       const declared = await sql<{ column_name: string; datetime_precision: number }[]>`
         SELECT column_name, datetime_precision FROM information_schema.columns
-        WHERE table_name = 'knowledge_connector'
+        WHERE table_schema = current_schema()
+          AND table_name = 'knowledge_connector'
           AND column_name IN ('next_member_sync_at', 'next_sync_at')
         ORDER BY column_name`
       expect(declared.map((c) => [c.column_name, c.datetime_precision])).toEqual([