Community: chat posts can still fill a Home's 4096-entry intake table (spam can stop Community for hours) #409

Problem

A Home's Community intake holds at most 4096 entries (MAX_INCOMING_RECORDS_AND_TOMBSTONES). Each accepted chat post keeps a replay record ("tombstone") for 24 h + 60 s. When the table is full, the Home refuses every new Community frame and evicts nothing (collaboration_core.rs:2105-2109). That Home then receives no Community posts until old entries expire, and posts sent to it during that time are not resent.

0.8.0 (alpha.22, #401) removed the cause seen in testing: presence no longer creates tombstones. Chat posts still do. So the table can still fill:

• Normal use: about 170 accepted posts per hour, around the clock, per Home. Far above today's traffic.
• Deliberate spam: the receiver allows 5 posts per Profile per 10 s (collaboration_rate_limit.rs:18-22). At that rate one Profile fills a Home's table in about 2 h 16 min (4096 / 0.5 per s), and several Profiles faster. A new Profile is a new install. Every Home that receives the spam stops receiving Community for hours.

Evidence

• 16 Oct: Anders's Mac and Jetson Homes (alpha.21 → alpha.22) received nothing. Both tables held 4096/4096 entries; 3685 on the Mac came from one sender at 240/hour, a presence heartbeat, accepted under alpha.21 (Community: presence replay records fill the 4,096 incoming table and stop intake #401 comment 6223137130).
• Both Homes were recovered by clearing the table with the Home stopped, keeping a backup (ops script community-table-reset.sh). That removes replay protection for up to 24 h on that Home. It is a manual workaround, not a product fix.

Constraints any fix must respect

• Replay protection: a frame accepted once must not be accepted again while it is still valid. Tombstone receipts today carry no message kind or expiry (collaboration_protocol.rs:64-75).
• Undo: state written by a new version must still load in the previous one (the alpha.21/alpha.22 state format).
• One sender must not be able to stop other senders' posts.

Ideas raised so far (none chosen)

• A per-sender share of the table (mitigation only: several Profiles still fill it).
• Retention tied to each message's own signed expiry, so a slot frees when the post expires (needs expiry in a signed record).
• Evicting the oldest entries when full (weakens replay protection).
• A supported way for a person to recover a Home whose table is full.

Milestone: After 0.8.0. Not a 0.8.0 blocker (Anders, 16 Oct): normal traffic does not reach the cap, and the presence cause is fixed in 0.8.0.