Say before the run when a writable mount is a Docker Desktop shared folder

[O6lvl4]

Closes #36.

On Docker Desktop, a macOS folder bind-mounted into a container is a fakeowner filesystem. Under Landlock, a command there can create a file but not write to it. Nothing in porta's ruleset causes this; the kernel refuses the open for writing whatever the grant says. Until now the command was left with an empty file and a bare Permission denied.

• native/sandbox_exec/linux.rs: ruleset() first reads /proc/self/mountinfo. If a writable -v lies on fakeowner, it prints this once:
  porta: /h is a Docker Desktop shared folder (fakeowner), where under Landlock a command can create a file but not write to it; give the command a Docker volume or a tmpfs to write to, and copy out after the run
  The filesystem is the deepest mount point that contains the path; when several are mounted on the same point, the last one listed wins. Octal escapes in mount points (\040) are decoded.
• docs/enforcement.md: the limit and what to use instead.

Verified

• The mountinfo parser's test passes: deepest mount, a mount stacked on the same point, a sibling prefix (/hx is not under /h), an escaped space, and empty input. I ran it on macOS with rustc, with the functions extracted from linux.rs. The #[cfg(test)] module in linux.rs is Linux-only, and CI does not run the Rust tests, so it only ran that way.
• This PR's Linux CI will be the first compile of the Linux code.
• Still to do: reproduce On Docker Desktop, a -v of a host-shared (fakeowner) directory is creatable but not writable under Landlock, and porta says nothing #36 end to end on Docker Desktop. I'll report the result here.

🤖 Generated with Claude Code