fix(gateway): isolate per-subscription failures in kanban notifier

[AlexFucuson9]

Summary

Fixes the kanban notifier getting permanently stuck when one subscription fails — blocking delivery for ALL other subscriptions.

Root Cause

The _collect() loop in _kanban_notifier_watcher iterates subscriptions without per-subscription error handling. When claim_unseen_events_for_sub raises for one subscription (e.g. DB corruption, lock contention, transaction rollback failure), the entire _collect() call aborts, which means:

1. ALL other subscriptions in that tick are silently skipped
2. The outer except logs "kanban notifier tick failed: cannot rollback - no transaction is active" — masking the real error
3. The notifier retries forever every 5 seconds, hitting the same error
4. No kanban→platform notifications are delivered for ANY subscription until the offending one is manually removed

Fix

Wrap the per-subscription logic inside the for sub in subs: loop in a try/except block. One bad subscription now logs a warning and continues to the next, instead of aborting the entire tick.

Testing

• Added regression test test_kanban_notifier_isolates_per_subscription_failure — verifies that when one subscription raises during claim_unseen_events_for_sub, the other subscription still gets delivered
• All 8 existing kanban notifier tests pass

Closes #59269

[teknium1]

Thank you for the focused notifier-isolation fix. The current collection loop has no per-subscription handler at gateway/kanban_watchers.py:254-293, so the proposed try/except directly addresses a real failure boundary.

Problems

• tests/gateway/test_kanban_notifier.py:326-332 creates the successful subscription before the failing one. hermes_cli/kanban_db.py:8692 selects subscriptions without ORDER BY; when that scan returns insertion order, current main sends the good notification before the bad claim raises, so this test passes without the fix.

Suggested changes

• Make the failing subscription deterministically appear first (for example by controlling list_notify_subs in the test), then assert the good subscription is delivered. That makes the regression fail on current main and verifies continuation after a failure.

Automated hermes-sweeper review.

[teknium1]

list_notify_subs() uses an unordered SELECT *, and this inserts the good row before the failing row. On an insertion-order scan, current main sends the good event before the bad claim aborts the tick, so this assertion passes without the fix. Please force the bad subscription to be returned first so the test proves continuation after failure.

[teknium1]

Merged via PR #72236 — your commit was cherry-picked onto current main with your authorship preserved. Your per-subscription isolation fix was the core of the jam repair (#59269); we hardened the regression test on top (the original passed without the fix due to subscription ordering) and added a cursor-snap fix for the related boot-storm. Thanks!