Defense-in-depth: support/document an in-guest least-privilege sandbox layer

Idea. For users wanting in-guest least-privilege on top of coop's VM boundary, support and document running an in-guest sandboxing layer (Landlock-based filesystem restrictions + seccomp user-notification syscall mediation) inside a coop guest. This composes with — rather than replaces — the disposable VM boundary, and is cheaper than reimplementing a filesystem/syscall sandbox from scratch (much of which is redundant with the disposable VM anyway).

Concrete blockers to resolve first:

1. Passwordless sudo. A no_new_privs-based sandbox disables passwordless sudo inside the guest — needs reconciling with coop's default guest UX.
2. Guest kernel config. The guest kernel must ship CONFIG_SECURITY_LANDLOCK + seccomp user-notification; coop currently treats its Firecracker CI kernel as fixed, so this needs a validated kernel config.
3. Docker socket. The root Docker socket in the guest is a straight bypass of any in-guest boundary — must be blocked or brokered.

Deliverable. A docs page (could live alongside the design/security docs) + a validated guest kernel config + an optional profile that installs the sandbox layer and its baseline policies.

Open question — how does an in-guest sandbox relate to coop? Undecided: design reference, optional in-guest layer, or a coop backend? This issue assumes optional in-guest composition; revisit the framing if that changes.

Refs. #2 (egress — an in-guest layer could provide the L7 layer) and #411 (credential non-exposure).

Start by validating the guest kernel requirements for Landlock and seccomp user-notification, then investigate passwordless sudo and the root Docker socket in the guest. Done means a docs page, a validated guest kernel config, and an optional profile with baseline sandbox policies, while resolving the stated composition framing.