Content(add): Post-incident monitoring of stolen funds (Monitoring framework) #662

The Monitoring framework covers a protocol's own contracts, treasury, bridges, and nodes, but nothing about what to watch after a theft. In the hours and days after an incident, the chance to freeze or hold funds is usually short and easy to miss: a stablecoin sitting in an attacker wallet, a gas top-up just before it moves, a deposit into a swap service or exchange.

I'd like to propose a sub-page, monitoring/post-incident-fund-monitoring, covering:

what to put on a watchlist after an incident (and how to keep it from exploding)
signals worth alerting on (stablecoin balances, gas top-ups, exits into services, mixers, privacy pools, bridges, CoinJoin)
noise that causes false alerts (address poisoning, failed explorer reads, dust)
how alerts hand off to freeze requests and the victim team

This complements #56 (tooling for on-chain monitoring) and #129 (community incident-response framework). I run continuous post-incident monitoring for public cases at onchainfiles.io and can write a first draft. Happy to adjust scope or placement (it could also live under Incident Management) based on steward feedback.