test(embed-directive): poll for async embed count before asserting

The caching-table test was asserting `fake.embedCallCount()` immediately
after a GET. The GET response returns before the cache write's txn commits
(Table.ts:~4275 design note), so the embed hook can fire on a later
event-loop tick. The assertion was racing with the async write.

Added a short polling loop (up to 500ms, 20×25ms) before the assertion —
consistent with the `search_by_hash` retry loop already in the same test
for the txn-commit lag.

Root cause of the regression: `88c94e67e` (yield event loop during
synchronous HNSW backfill) changed event-loop scheduling globally; this
made the race window between the GET response and the embed call wider,
exposing the pre-existing fragile assertion on Node.js v26.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Author: kriszyp

integrationTests/server/embed-directive.test.ts

@@ -420,7 +420,14 @@ suite('@embed directive end-to-end with fake Ollama', (ctx: any) => {
 		strictEqual(firstBody.id, id);
 		strictEqual(firstBody.content, expectedContent, 'cache should reflect the source-returned content');
 
-		// The embedder must have run exactly once during the cache write.
+		// The cache write fires the embed hook asynchronously — the GET response is
+		// returned before the write's txn commits (see Table.ts:~4275 design note),
+		// so the embed call may land on a later event-loop tick. Poll up to ~500ms
+		// (same approach used below for search_by_hash) before asserting.
+		for (let attempt = 0; attempt < 20; attempt++) {
+			if (fake.embedCallCount() > baselineEmbedCalls) break;
+			await new Promise((resolve) => setTimeout(resolve, 25));
+		}
 		strictEqual(
 			fake.embedCallCount(),
 			baselineEmbedCalls + 1,