… on late enable

Two related FITB#122 bugs in the local-fallback UX surface:

nesquena#122 #6 — Reactive failover modal never appears on provider failure

The frontend ELIGIBLE_TYPES set was {stream_interrupted, rate_limit,
no_response, unknown}. The original comment said auth/quota errors are
excluded because "local model can't fix the user's wrong key / empty
wallet." That misread the value: local fallback REPLACES broken cloud
entirely so the user can keep working, regardless of why cloud broke.
Auth and quota are exactly when the fallback offer makes sense.

Backend (api/streaming.py) actually emits these types: 'auth_mismatch',
'quota_exhausted', 'stream_interrupted', 'no_response'. The previous
'rate_limit' entry was dead — backend never emits it. Reconciled with
the real backend vocabulary.

nesquena#122 #7 — Recovery banner never appears after enabling fallback

startRecoveryPolling() was only called from boot, gated on the
/api/local-fallback/status check at page load. The most common user
flow — provider failure → enable fallback in Settings → correct API
key → expect banner — never started polling, because at page-load
fallback was off.

Fix: panels.js's onLocalFallbackToggle now dispatches a
'fitb:fallback-enabled' window event after a successful enable,
fallback-polish.js's boot listens for it and calls
startRecoveryPolling. The function is already idempotent (returns
early if the timer is set), so this is safe alongside the existing
boot-time call for the steady-state case.