Health aggregate: distinguish unconfigured providers from degraded ones

[iceteaSA]

Signal-quality issue in ck health / the aggregate insula health line.

Observed

On this box (7-ish credentialed provider families), the health line reads:

insula  ● ok  29/35 providers degraded, 6 serving; 0 of 9 cookie logins stale

The 29 "degraded" are overwhelmingly providers we have never configured — no credential source exists on this machine for them. That makes the aggregate line a permanent alarm: a real degradation (a provider we DO use failing auth) would change the count by 1 against a baseline of 29, which nobody notices. The useful signal today is only the serving count and the cookie-staleness clause.

Ask

Distinguish unconfigured (no credential source discovered — expected, excluded from the alarm count) from degraded (credential source present but fetch/auth failing — actionable). The line becomes something like:

6 serving · 1 degraded · 28 unconfigured

with degraded > 0 as the operator trigger. If discovery can't currently tell "no source" apart from "source errored", that distinction is probably worth carrying in the provider snapshot anyway — it's the same split our local fetchers ended up needing (fail-open on stale vs fail-loud on drift) for the guard verdicts downstream.

Happy to contribute the classification if pointed at where provider snapshot state lives.

[ualtinok]

Fixed, 761e21f. unconfigured is now its own bucket beside serving and
degraded, so a provider with no credential on this host no longer dilutes the
count of ones that are actually failing.

The same box now reads:

insula  ● ok  9 serving, 2 degraded, 25 unconfigured of 36; 1 of 9 cookie logins stale

degraded is ["opencode", "qoder"] — two providers with credentials present
and failing, which is the number worth alerting on. Previously both were inside a
27 that was mostly absent credentials.

Two details from doing it that are worth having if you consume the metrics:

A provider counts as unconfigured only when ALL of its accounts are. One
credentialed account failing beside absent siblings keeps the provider in
degraded, where it can be seen. Relaxing that to "any" was the first thing I
tried and it made a provider with one broken credential vanish into the quiet
bucket — the exact failure this issue reports, one level down.

cookieLoginsStale was counting the same way and is also fixed (5ceef8f).
It was a deny-list (errorClass != credential_absent), so a browser profile
that had never been logged into counted as a stale login, and it sat pegged at 9
of 9 here. It is now an allow-list over the two classes that actually mean an
expired session, and reads 1 of 9.

The conservation identity is unchanged and still worth asserting:
fresh + stale + pending + len(degraded) + len(unconfigured) + len(withoutHandles) == providersTotal, gated on lastTickAgeSecs being non-null so it does not fire
during warm-up. Documented in docs/consumer-contract.md.