docs: state the accidents-not-adversaries threat model; add ROADMAP

The gates in front of destructive operations exist to stop mistakes
(stale rosters, typos, racing hosts); stopping a malicious group
member is a side effect, not the design goal. Written into README
§Security and the man page so future checks are judged by that bar.
ROADMAP.md captures the direction: social features (knock, log,
clean) over further hardening, plus the explicit resist list.

README.md

@@ -92,6 +92,8 @@ The mechanism is identical everywhere: group ownership and mode bits plus `tmux
 
 `party` assumes you already know and trust everyone you add to the group; it is not a public access-control system. Both gates above protect each party, and the **auth gate** (`tmux server-access`) is authoritative, with the filesystem gate as defense in depth.
 
+The threat model is **accidents, not adversaries**. `party` runs where everyone already shares the box, so the ownership and symlink gates in front of destructive operations (`close`'s directory removal, moderation) are there so a stale roster, a typo, or two racing `party host` invocations can't remove or hijack the wrong thing — that the same checks would also stop a malicious group member is a side effect, not the design goal. New checks should earn their place by preventing a plausible *mistake*, not by closing a hypothetical attack from a friend.
+
 Three honest caveats, with the full detail in `man party`:
 
 - On ACL-enabled filesystems (ZFS, HFS+/APFS), inherited ACLs can override the mode bits, so the FS gate is best-effort. The auth gate still holds.