Add security hardening notes: pidfd proposal, unotify observational limits

[Mohamed-elnady]

Third and final PR of the hardening series (follows #339 and #340).

Adds docs/security-hardening-notes.md:

• Changelog for the hardening flags and fuzz targets from the previous two PRs.

• A proposal for pidfd-pinned process management. nsjail's parent writes uid_map/gid_map/setgroups and derives observation fds via unpinned /proc/ paths across the fork→handshake window. We verified experimentally that the kernel accepts privileged uid_map writes into an unrelated fresh user namespace under this pattern. Our exploitation-blocked analysis (no kill primitive in root deployments; identity maps only in same-user deployments) was submitted to Google's vulnerability intake for assessment (issuetracker 561676647); Google's triage reviewed it and directed publication here. The pattern is fragile by construction — runc migrated to pidfd for exactly this reason. Design sketch included; happy to implement it as a follow-up.

• Documented observational limits of --seccomp_unotify. It is an audit feature: the supervisor always responds SECCOMP_USER_NOTIF_FLAG_CONTINUE and never denies. Syscalls issued via io_uring are invisible to it (io_uring_setup/enter/register are not in the trace table) — demonstrated with a differential PoC. Operators relying on unotify for forensics should know; adding the three io_uring syscalls to the trace table would at least reveal io_uring usage.

(Both items were assessed through Google's vulnerability intake before this public documentation; intake reference 561676647.)