fix(usage-queue): warn each pane on cred failure, not just the first

[aterrylu]

Problem

Follow-up to #232. A review thread on that PR flagged a real bug in the usage-queue's credential-failure warning: authFailureNotified was a single global boolean, so the "warn each armed pane once" intent was actually implemented as "warn at most once across all panes."

Concretely:

1. Creds break (e.g. expired session key).
2. Pane A is armed → tick observes unauthorized → A is warned, authFailureNotified = true.
3. Hours later (still broken), pane B is armed → tick sees authFailureNotified already true → B is never warned.

B now has a queued auto-send that can never fire and the user has no idea — a silent failure of the exact contract that warning exists to enforce.

Fix

Move the latch from a single global boolean to a per-pane authWarned flag on ArmedEntry:

• On a permanent credential failure, warn any armed pane not yet warned — including one armed after an earlier warning while creds stayed broken.
• Reset each pane's flag when a real usage signal returns (so a later break re-warns).

Testing

• New regression test: warns a pane armed AFTER creds break, while they stay broken — arms one pane, warns it, then arms a second pane while still broken and asserts it's also warned (and the first isn't re-warned).
• Existing auth test (warns each armed pane once) still passes — no re-warn spam, fires both on recovery.
• Full suite green: server + 254 dashboard.

Note

This PR's base branch (main) now requires conversation resolution before merging (newly enabled), so a future unresolved review thread can't slip through to merge the way the original did.

🤖 Generated with Claude Code

https://claude.ai/code/session_01UpGRD3fxgWmCKyp9nZtrQs

[nox-0x]

Approving — clean targeted fix for the per-pane vs. global auth-warning latch flagged on #232, with a regression test that exercises the exact failure mode (pane armed after first warning, while creds stayed broken) and the existing 'warn each pane once' and 're-warn on recovery' contracts still hold. Reset loop and arm-time initialization are both in the right place; nothing else to flag.