seccomp: audit and harden Continue-site safety (issue #27)

[congwang-mk]

Summary

Addresses #27 (the second of the reporter's two asks — explain why each NotifAction::Continue is safe — plus one concrete hardening surfaced by the audit).

• Commit 1 (3c2acc0): walk every NotifAction::Continue site (~130 across 10 files) and add module-level safety contracts. Three categories surfaced — pass-through fall-throughs, register-arg decisions (TOCTOU-immune), and path-rewrite-then-Continue. Only the third category is a real TOCTOU surface; it appears at handle_chroot_exec (already commented in feb8328) and handle_chroot_chdir (newly inline-flagged with the same template). Comments only — no semantic changes.
• Commit 2 (aad2a66): fix the one soft weak spot the audit identified — sendmsg_on_behalf previously fell through to Continue if read_child_mem on the msghdr struct failed, which a racing thread could force by briefly unmapping the address. Returns Errno(EFAULT) instead, refusing the syscall rather than letting it slip past the IP allowlist check.

The remaining structural TOCTOU (chroot exec/chdir path rewrite) is bounded by Landlock and called out for an opt-in CLONE_THREAD deny in a follow-up.

Test plan

• cargo check --workspace clean
• cargo test --workspace (run by CI)
• Reply on issue Sandbox escape by racing seccomp notifications? #27 referencing this PR

🤖 Generated with Claude Code