kernel: lockdown at confidentiality and the BPF LSM

[aledbf]

The guest kernel now runs lockdown (forced to confidentiality) and the BPF LSM, and no longer builds /dev/mem or /proc/kcore. Root in the guest can neither read nor rewrite the kernel, and a consumer can enforce policy with BPF LSM programs it loads before the tenant's init. This is the first step of spin's F2b ("the guest defends itself").

Changes

• Config: SECURITY, SECURITYFS, SECURITY_NETWORK, SECURITY_PATH, BPF_LSM, SECURITY_LOCKDOWN_LSM(_EARLY), LOCK_DOWN_KERNEL_FORCE_CONFIDENTIALITY and LSM="lockdown,bpf" on; DEVMEM and PROC_KCORE off.
• Build check: kernel/Dockerfile fails if olddefconfig drops any of these, or turns DEVMEM, PROC_KCORE, MODULES or KEXEC back on.
• Guest test: task boot:lockdown boots a disposable guest and asserts lsm = lockdown,capability,bpf, [confidentiality], and that root cannot lower it. The logind check now shares its boot helper.
• Measured with task boot:initcalls, 20 interleaved boots each against main's kernel: no cost distinguishable from noise (p50 196.3 vs 208.3 ms on a loaded host). The numbers are in kernel/README.md.
• Visible change: systemd logs use of bpf to read kernel RAM is restricted at boot and carries on; logins are unaffected (task boot:logind passes).

This is a new machine: the kernel's content changes, so every existing checkpoint stops resuming.

🤖 Generated with Claude Code

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}