Round 2: Wallet alerts, every token

Cairn watches wallets for a chat across every token on Starknet, not only the registry, and delivers every
alert exactly once. Round 1's commands, formats and checks stay as they are.

**Commands.** `/watch <address> [label]` (a label of at most 32 characters, escaped), `/unwatch <address|label>`,
and `/list` with a Remove button per subscription. `/whale <SYMBOL|token address> <amount>` posts every
transfer of that token at or above the amount, labelling mints and burns; `/unwhale <SYMBOL|token address>`
stops it. `/min <SYMBOL|token address> <amount>` sets the chat's floor for watch alerts on that token.
`/mute <token address>` silences one token in the chat (for spam airdrops) and `/unmute <token address>`
undoes it. `/balance <address> [SYMBOL|token address]` gains an optional token, which may be any ERC-20; for an
address watched in the chat, `/balance` also lists the non-zero balances of the tokens seen moving for it
since the watch began. `/track <hash>` posts once on L2 acceptance
(execution status and fee), then once on L1 acceptance or on a revert with its reason, and says "not found"
after 600 s of chain time. `/export` replies with everything stored for the chat as JSON
(`{"chat_id","watches","whales","minimums","tracks","muted"}`), and `/forget` deletes it all. In a private chat, a
pasted address gets the `/balance` reply with a Watch button, and a pasted hash the `/tx` reply with a Track
button. In groups, everything but `/list` needs an administrator, anonymous ones included; a refusal says
why. Caps: `CAIRN_MAX_WATCHES` (default 20) watches per chat, 5 whale thresholds, 10 tracks; a user's
commands beyond 10 in 60 s of `message.date` get one slow-down notice, then are ignored until the window
passes.

**Scanning.** Each pass scans the blocks after the cursor, at most `CAIRN_MAX_BLOCKS` (default 500), with one
chain-wide `starknet_getEvents` filter: keys `[[Transfer, Approval]]`, no address, `chunk_size` 1000 (some
providers refuse more than 1024), following every `continuation_token`. Mainnet emits about 17 such events
per block, so a pass at the default poll reads one page, and a 500-block catch-up about nine. Each event is
decoded by its shape: keys `[sel, a, b]` with data `[low, high]` is a modern ERC-20 event; keys `[sel]` with
data `[a, b, low, high]` is a legacy ERC-20 event when its contract answers `decimals`, and otherwise a legacy
NFT, which is ignored; any other shape (such as an NFT with its token id in the keys) is ignored. A
subscription covers only the blocks after the head read in the pass that handled its command; the first
start never backfills. Never alerted: zero-amount transfers (address poisoning), fee payments (the STRK
`Transfer` from the sender to the block's `sequencer_address`, the last event of its transaction), transfers
under the chat's `/min`, and muted tokens.

**Tokens outside the registry.** The registry lists the verified tokens. Any other contract is read the
first time one of its events matters: `symbol` (a short string or a ByteArray) and `decimals` (0 to 36; any
other answer, or none, means it is not a coin and its events are ignored), cached for 7 days of chain time.
Such a token is shown as its symbol in `<code>` (escaped, at most 11 characters, never a link), followed by
"unverified" and its short contract address linked to the explorer, so an airdropped fake "USDC" never
passes for the real one.

**Alerts.** One message per chat per transaction, in chain order, listing each matching transfer: token and
exact amount, in, out or "between" (naming both addresses when both are watched), counterparty, label, block
time and transaction link. An `Approval` by a watched owner, on any token, shows the spender and the amount,
or "unlimited" for at least 2^128 − 1. Delivery is keyed by (chat, transaction hash, `event_index`): saved before it is
sent, marked sent only once Telegram accepts it, so after a kill every alert arrives and none arrives twice.

**Telegram.** `allowed_updates` adds `callback_query` and `my_chat_member`; the methods
`answerCallbackQuery`, `editMessageText` and `getChatMember` join round 1's. A 403, or a `my_chat_member`
update to `kicked` or `left`, pauses the chat until it writes again or re-adds the bot. A
`migrate_to_chat_id` moves the chat's data to the new id and resends. `tick`'s line adds `"alerts"` and
`"cursor"`. No user's name or username is ever stored. Round 2's checks are written once round 1 settles,
on top of its winner.

## How to run it

On mainnet, `/watch` two addresses you control, move a little STRK and a token outside the registry between them, and approve a spender; in a test group, set `/whale STRK 1000000`.

- C1 (alert quality): read an hour of alerts as a busy holder would.
- C2 (delivery correctness): `kill -9` the bot during a burst, restart it, and compare the alerts with the explorer.
- C3 (admin control and privacy): set the group up as an admin, try the same as a member, then run `/export` and `/forget` and inspect `CAIRN_DATA`.
- C4 (code quality): read how the scanner is separated from the alert rules, and imagine adding a swap feed.