fix(kanban): don't classify unobserved worker exits as systemic failures

[julio-cloudvisor]

Problem

After a dispatcher restart, the next sweep can find several tasks still recorded as running even though their worker PIDs are dead. The new dispatcher cannot recover the exit status because the reap registry was in the old process, so each death becomes the same normalized pid N not alive error.

The systemic-failure detector groups three or more identical fingerprints and forces an effective failure limit of one. A restart with several in-flight workers can therefore mass-block healthy cards on first contact, even when the configured failure limit is higher.

We have seen this in a multi-profile deployment: one dispatcher restart left four healthy cards with unclassified dead workers, and the shared fingerprint sent all four directly to gave_up after one counted failure.

Current main still includes every crash detail in the systemic fingerprint count. It does not distinguish the unknown exit kind from an observed non-zero exit or fatal signal when deciding whether to collapse the limit.

Fix

Carry an unclassified bit with each crash detail and exclude those rows from the systemic-failure accelerator. An unclassified worker still counts one ordinary failure against the task's configured limit; it simply cannot make a cohort systemic when the only shared fact is that the dispatcher lost their exit evidence.

That conservative boundary is intentional. The durable state cannot distinguish a worker killed by the restart from a genuine SIGKILL or OOM death whose dispatcher disappeared before persisting the status. Treating every unknown exit as no-fault would hide real crashes. Keeping the ordinary failure while declining to collapse the limit avoids both errors.

Observed exits remain unchanged: repeated matching non-zero exits or crash signals can still trigger the systemic accelerator.

Testing

The carried patch covers the ambiguous and observed cases separately:

• an unclassified worker death under a live dispatcher still counts as an ordinary crash;
• a worker death followed by claimer death still counts, proving the patch does not infer a no-fault restart from PID liveness;
• four concurrent unclassified exits each record one failure but do not force the systemic limit, so the cards remain retryable under the configured limit;
• a cohort of matching, observed real crashes still takes the systemic path and trips immediately.

Before opening the PR I would rebase and run the full kanban database suite on current main.

Test run

Rebased on current main and re-verified:
scripts/run_tests.sh tests/hermes_cli/test_kanban_db.py tests/hermes_cli/test_kanban_core_functionality.py — 57 passed, 0 failed.