fix(notifier): resolve waitWebSocket promise on WS error to prevent pull-loop wedge

[jbiskur]

Summary

• Resolves waitWebSocket() promise immediately on RxJS subject error() instead of waiting up to 20 s for the timeout, eliminating the per-source pull-loop wedge observed in data-pathways production on 2026-05-10.
• Binds the awaited promise + eventResolver before notificationClient.connect() so a synchronous error during connect cannot race against an unbound resolver.
• Wraps the inner await in try/finally so notificationClient.disconnect() runs on every exit path (error, timeout, success, abort) — fixes a pre-existing socket leak on the error path.
• Adds _internals.createNotificationClient test seam so the WS subject lifecycle can be driven deterministically in unit tests. Not part of the public API.

Why

Production incident 2026-05-10: PAT events written to flowcore stopped propagating to Usable. Root cause located in src/data-pump/notifier.ts:107-140: subject's error handler only logged, so the awaited promise never resolved on WS disconnect. Loop spun on 20 s timeouts with no events flowing. Full investigation in Outage fragment bddefdd2-c377-472a-bc50-cd75f708f822.

Test plan

• deno fmt --check
• deno lint
• deno check src/mod.ts
• deno test -A test/tests/notifier.test.ts — 8 cases, 0 failures
• deno test -A — full suite, 10 passed (47 steps), 0 failed
• TDD discipline: tests cases 1, 3, 6, 7, 8 confirmed to fail meaningfully against pre-fix code

Tests cover

1. WS error during wait() resolves the promise within 50 ms (regression for the wedge)
2. Subject is recreated per wait() call
3. After a WS-error cycle, the next wait() delivers events normally
4. Timeout-only path resolves around the configured boundary
5. AbortSignal resolves promptly
6. disconnect() runs on every exit path (error, timeout, success, abort)
7. No double-resolve crash when next() fires on a terminated subject
8. Synchronous error before connect() resolves: wait() resolves cleanly

🤖 Generated with Claude Code