fix(recall): bound the embedding call so one slow upstream cannot hold recall open

[MXAntian]

generateEmbedding had no timeout. Hybrid recall awaits it, so a single slow upstream call held the whole request open for as long as the network took.

Measurement

14-day recall log, 2404 calls:

query_path	n	slow (≥3s)	avg
sync	844	0	9ms
strict	144	0	60ms
hybrid	1416	282	2527ms

Every slow call is on hybrid — the only path that embeds. Overall p50 = 327ms, p90 = 10635ms. That's not a tail, it's a second mode.

The hybrid distribution has an empty middle:

p50  501ms · p70  919ms · p80 2290ms  |  p85 10695ms · p90 10734ms · p95 10880ms

Nothing lives between ~3s and ~10s. That's the shape of an upstream stall, not of our work getting slower under load.

This wasn't the diagnosis we had

It was on the books as "the resident server has a ~10s cold start, go find out where the server spends it." Two things kill that reading:

• Idle doesn't predict it. Median gap before a slow call is 3 min, before a fast one 1 min. 16% of slow calls follow a ≥10min gap, vs 11% of fast ones. No correlation.
• The server isn't where the time goes. It's an outbound HTTP call with no deadline, on the hot path, inside a Promise.all.

The waiting also bought nothing: FTS runs in that same Promise.all and is synchronous, so its rows were already in hand. The request just sat on the socket holding them.

Fix

AbortSignal.timeout, default 2500ms, EMBEDDING_TIMEOUT_MS to override.

2.5s cuts the entire stall cluster — 282 of the 286 calls it touches — at the cost of one legitimately slow embed. Tightening to 1s would eat 84 more real ones and gain nothing, since the cluster is already gone by then.

Resolved per call, not at module load: capturing env at import time makes the knob untunable by anything that configures itself after the import — which is every embedder of this library, and every test. Same trap as the DB path.

Degradation stays visible

A timeout returns null, the vector leg is skipped, RRF proceeds on FTS rows. That's a quality degradation, so it's labelled rather than swallowed:

• result carries _degradedTo / _degradeReason = 'embedding-timeout', matching what the early-bail branch already sets
• the timeout logs as its own line instead of reading like a broken upstream

Fast-and-quietly-worse is the failure mode this guards against.

generateEmbedding is now exported. The timeout is only testable through it — going via recallMemoriesHybrid can't discriminate on a machine without the sqlite-vec extension (CI), because that path early-bails to FTS before it ever embeds and would pass either way.

Verification

Red-then-green with the timeout removed:

✓ the stalling endpoint was actually reached (fixture is wired up)
✗ a stalled embedding gives up on schedule — took 30024ms, budget 600ms, stall 30000ms
✗ a timed-out embedding returns null rather than throwing — got object
✓ a healthy embedding still comes back
✓ a healthy embedding is not delayed by the timeout machinery
✓ recall still returns rows — it degrades, it does not fail
✗ a timeout is recorded as its own degradation reason — _degradeReason=undefined
FAIL: 4 passed / 3 failed

It waits out the entire 30s stall. Exactly the three assertions that matter fail; both healthy-path assertions stay green, so they aren't coupled to the fix.

Full suite green: embedding-timeout 7 · cold-pool 6 · recall-contract 14 · ranking-importance 5 · recall-endpoint 17 · query-rewrite 6 · memory-health 68 · locations 51 · provenance 25 · encoding-damage 18 · injection-hygiene 14 · level-migration 10 · supersede-shrink 24 · anchor-pinned 4.

Risk

That 20% of calls now returns FTS-only results — worse ranking, same answer. If recall starts feeling dumber, check the share of calls carrying _degradeReason='embedding-timeout' first: a high share means fix upstream connectivity, not raise the timeout back.