Global cross-account backoff: stop resolve dispatch to all accounts after long FloodWait

[axisrow]

Parent issue

Sub-issue of #464 — proposed fix item 4 (partially implemented).

Problem

PR #502 implemented a process-local backoff for the account that received the flood wait. But the collector does not propagate this backoff to other accounts — it continues dispatching resolve_username on the next available account, which then also gets a long flood wait.

Production evidence (2026-05-03, data/app.log):

• +66982102247 gets 66230s flood at 01:57:33
• +66990712629 starts collecting at 10:14 and gets 56785s flood at 10:28 — same cycle of escalation

The per-account backoff protects the flooded account from further hits but does not protect the pool from walking into the same trap on the next account.

Proposed fix

When any account receives a resolve_username flood wait exceeding a threshold (e.g., > 300s), set a global resolve backoff that blocks all accounts from performing live resolve_username calls:

• Scope: process-wide flag, not per-account
• Duration: min(wait_seconds, 3600) from the triggering event (same as proposed in Collector resolve_username without rate-limit triggers 16h flood-wait on all accounts #464)
• Effect: _resolve_channel_input_entity() falls back to cache-only mode — if InputPeer cache misses, defer the channel instead of calling live API
• Reset: auto-expires after duration; cleared on next successful resolve

Files

• src/telegram/collector.py — global backoff state + check in _resolve_channel_input_entity()
• src/collection_queue.py — reschedule with appropriate note

Acceptance criteria

• After one account gets long flood wait, no other account attempts live resolve for the backoff window
• Cache-based resolves continue working during global backoff
• Collection tasks are deferred with clear note explaining global backoff
• Tests for global backoff behavior