v0.2.0

Added

• devalerts.init_celery(): reports Celery task failures automatically via
  the task_failure signal. init()'s excepthook alone never sees
  exceptions raised inside a task, since Celery catches those itself to
  record the task's FAILURE state — same class of problem ASGIMiddleware
  solves for ASGI request errors. Tags each alert with the task name and id.
  Celery is imported lazily, not a devalerts dependency.
• Every alert now includes the sending host (socket.gethostname()) — useful
  when one bot serves multiple processes/servers. init(tags={...}) adds
  global tags to every alert; report(extra={...}) / capture(extra={...})
  add ad-hoc tags to a single call, overriding init()'s tags on key
  collision.
• Chronic error groups (occurrences piling up while rate-limited) now back
  off exponentially: each chronic resend doubles the effective
  rate_limit_seconds for that group, capped at 8x. A group that goes quiet
  and reappears once (no pile-up) resets to the base rate immediately.
  dashboard/--json show the active multiplier.
• devalerts mute <fingerprint> / devalerts unmute <fingerprint>: silence
  or re-enable alerts for a specific error group without touching code.
  Unmuting resends with the accumulated skip count, same as a rate-limit
  window expiring.
• devalerts clear <fingerprint> / devalerts clear --all: delete error
  group(s) from local state. All three commands accept a unique prefix of
  the fingerprint (the ID column shown by dashboard).
• devalerts dashboard --json: machine-readable output for scripting.
• devalerts test --bot-token ... --chat-id ... CLI command: sends a one-off
  message so you can verify bot_token/chat_id are wired up correctly
  before touching any code.
• Test coverage for ASGIMiddleware (previously untested) and for
  _excepthook/_threading_excepthook's "must never raise" guarantee,
  raising overall coverage from 86% to 95%.
• GitHub repo topics for discoverability.

Fixed

• devalerts dashboard now uses each error group's actually configured
  rate_limit_seconds (persisted to the local DB) to decide limited vs
  sending status, instead of always assuming the library default.

Changed

• _send_telegram_message now returns True/False instead of None, so
  callers (like the new test command) can tell whether delivery succeeded.
• Telegram delivery now retries once on failure (honoring Retry-After on a
  429, up to 10s) before giving up. If every attempt fails, the message is
  appended to ~/.devalerts/failed.log instead of just being dropped.