Validate bond sizing against spam and griefing scenarios

[comzzy-comzzy]

Summary

Closes #50.

I added a bond-sizing analysis for Tholos so the deployment docs no longer rely only on general advice for bond_amount.

I covered the main cases from the issue:

• I modeled low-value assertion spam and how much attacker cost each spam attempt should carry.
• I modeled bad-faith disputes that can delay finality and waste resolver time.
• I looked at resolver self-rotation griefing and explained why this is mostly handled through committee/admin operations, not by increasing bond_amount.
• I looked at finalize_reward_bps griefing and showed how the reward affects the asserter haircut and finalizer incentive.

I also updated DEPLOYMENT.md to point to the new sizing model, and I checked off the mainnet-readiness item for modeled spam/griefing validation.

Notes

This does not mark Tholos as mainnet-ready by itself. The independent audit and real-world dispute-volume checklist items are still open.

[collinsezedike]

Thanks for this, it's a genuinely rigorous piece of work.

The formulas are internally consistent, and every worked example's arithmetic checks out.

The resolver-rotation-griefing section accurately describes the real contract mechanics (single open proposal, deadlock auto-cancel, no effect on in-flight disputes, admin override) rather than hand-waving it.

The DEPLOYMENT.md checklist update is honest too, "modeled" rather than overclaiming "real" validation, leaving that distinction for #13.

Nice work, take a look at the other open issues when you get a chance.