fix(indexing): yield the event loop during a synchronous custom-index backfill

A custom index (HNSW vector index) indexes synchronously: in runIndexing's
per-row loop, index.customIndex.index() runs inline and returns void, so it
never assigns lastResolution and never raises `outstanding`. The existing
yield is gated on `outstanding > MIN_OUTSTANDING_INDEXING`, so for a
custom-index backfill it never fires — the entire backfill over the populated
rows runs in a single event-loop turn, freezing the worker's main thread for
the whole build (starving replication keepalive, the operations API, and
schema signalling, and never letting isIndexing be observed; vector search
returns 503 the entire time).

Track whether a row performed synchronous custom-index work and yield once per
such row when the outstanding-based yields don't apply.

Validated on a live 5.1.0-beta.1 instance with a 100ms main-thread heartbeat
over an identical 2,000-row int8 HNSW backfill (clean A/B, same box/data):
  before: max event-loop stall 71,030 ms (frozen for the entire 71.2s build)
  after:  max event-loop stall    166 ms; build 67.5s (no measurable throughput cost)

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Author: 2 people

resources/databases.ts

@@ -1334,6 +1334,10 @@ async function runIndexing(Table, attributes, indicesToRemove) {
 				// TODO: Do we ever need to interrupt due to a schema change that was not a restart?
 				//if (Table.schemaVersion !== schemaVersion) return; // break out if there are any schema changes and let someone else pick it up
 				outstanding++;
+				// Custom indexes (e.g. HNSW) index synchronously and never raise `outstanding`, so the
+				// outstanding-based yield below never fires for them. Track that this row did synchronous
+				// indexing work so we can still yield the event loop after it.
+				let didSynchronousIndexing = false;
 				// every index operation needs to be guarded by the version still be the same. If it has already changed before
 				// we index, that's fine because indexing is idempotent, we can just put the same values again. If it changes
 				// during the indexing, the indexing here will fail. This is also fine because it means the other thread will have
@@ -1347,6 +1351,7 @@ async function runIndexing(Table, attributes, indicesToRemove) {
 						const value = record && (resolver ? resolver(record) : record[property]);
 						if (index.customIndex) {
 							index.customIndex.index(key, value);
+							didSynchronousIndexing = true;
 							continue;
 						}
 						const values = getIndexedValues(value, index.indexNulls);
@@ -1385,7 +1390,9 @@ async function runIndexing(Table, attributes, indicesToRemove) {
 					if (interrupted) return;
 				}
 				if (outstanding > MAX_OUTSTANDING_INDEXING) await lastResolution;
-				else if (outstanding > MIN_OUTSTANDING_INDEXING) await new Promise((resolve) => setImmediate(resolve)); // yield event turn, don't want to use all computation
+				else if (outstanding > MIN_OUTSTANDING_INDEXING)
+					await new Promise((resolve) => setImmediate(resolve)); // yield event turn, don't want to use all computation
+				else if (didSynchronousIndexing) await new Promise((resolve) => setImmediate(resolve)); // custom indexes (e.g. HNSW) index synchronously and never raise `outstanding`; without this yield a large backfill runs in a single event-loop turn, starving keepalive/replication and queries and never letting the isIndexing flag be observed
 			}
 		}
 		// Await the last pending put. If it rejects, that is also an indexing error.