fix(agents-server): dropped parent wake on parallel sub-agent spawn

[andresberrios]

Problem

When a parent spawns two (or more) sub-agents in parallel — both spawn_worker-style tool calls issued in the same turn, as a model naturally does when fanning out — only one of the children ever wakes the parent on completion. The other child's runFinished is silently dropped: no error, no warning. Spawning the same children sequentially always works.

Root cause

Each child's runFinished wake is registered from two independent paths, both keyed by the same manifestKey:

• spawn path — entity-manager.ts spawnInner (if (req.wake) wakeRegistry.register(...))
• manifest-sync path — runtime.ts syncManifestWakes → wakeRegistry.register(...), when the parent's manifest entry for the child lands on the parent's stream.

register() inserts with .onConflictDoNothing() against uq_wake_registration. The second path to run gets an empty result and previously took this branch:

if (result.length === 0) {
  await this.loadRegistrations()  // full clear-and-rebuild of the cache
  return
}

loadRegistrations() snapshots all rows across an await, then resetCachedRegistrations() clears the entire in-memory cache and rebuilds from that snapshot. Parallel spawn issues up to 4 register() calls (2 children × {spawn, manifest-sync}); several land in the conflict branch and their reloads interleave. If a stale snapshot's continuation runs last, it clears the cache and rebuilds without a sibling's newer registration — evicting it even though the DB row exists. When that sibling then finishes, evaluate() reads only the in-memory cache, finds no match, returns [], and the wake is dropped with no error path hit.

Sequential spawn never overlaps the reloads (each child fully registers and delivers before the next spawns), which is exactly why only the parallel fan-out reproduces.

Fix

In register()'s conflict branch, re-read only the single conflicting row (by its uq_wake_registration columns) and upsertCachedRegistration() just that entry. No global cache reset → no cross-registration clobber.

Test

Adds a regression test in test/wake-registry.test.ts: registers two siblings for the same subscriber where the second hits the conflict branch against a stale full-table snapshot (missing the first), then asserts both still evaluate() to a match. Fails on main (first sibling evicted → evaluate returns []), passes with the fix. Full wake-registry.test.ts suite (34 tests) green.

[andresberrios]

Follow-up: pushed two commits that fix a different parallel-spawn wake drop than the original clobber this PR addressed.

The original fix guards register()'s on-conflict loadRegistrations() path. But sibling sub-agents spawned in one turn register distinct sources, so they never hit that conflict path — and a patched build still dropped wakes. Root cause turned out to be ElectricAgentsTenantRuntime.syncManifestWakes: for each child's manifest entry it did unregisterByManifestKey() → await register(), non-atomically removing then re-adding a registration that's identical to the one the spawn already created. During the await the registration is absent from the in-memory cache; a sibling finishing in that window has its runFinished wake silently lost.

• deb8c53 adds WakeRegistry.reconcileManifestRegistration (register-first — register() now returns the kept dbId — then prune only stale rows by that exact id) and routes syncManifestWakes through it. No gap.
• 781c9eb routes the same latent unregister→register pattern at upsertCronSchedule and upsertWebhookSourceSubscription through the same gap-free helper.

Verified with a new pull-wake e2e (parent spawns 6 workers in parallel via the real runner + mock LLM): every child's wake now reaches the parent's stream across 15/15 runs; it dropped ~1-in-1..1-in-3 before. Two deterministic unit tests added; existing wake-registry suites (36) unchanged.

Note: the pull-wake runner legitimately coalesces multiple wake events into one handler invocation, so the guarantee asserted is at the production layer (one wake event per child on the parent stream), not handler-invocation count.