Hardening: split libkrun/VMM processes for finer-grained seccomp after xattr allowlist

Nobody has claimed this yet.

## Context

PR #846 fixes writable virtiofs volumes by allowing the Linux xattr syscall family in the VMM seccomp profile. That is a practical compatibility fix: host-side virtiofs handling can call `fgetxattr`/related syscalls while preserving file metadata such as `security.capability`, and blocking those syscalls SIGSYS-kills the VMM during otherwise normal writes.

However, the current seccomp granularity is VMM-process-wide. The `vmm` filter is applied with TSYNC to all threads in the shim/VMM process, so the xattr allowlist is available not only to the virtiofs path that needs it, but also to other threads sharing the same process boundary, such as libkrun runtime threads and embedded networking/helper threads.

## Problem

This is acceptable as a short-term unblocker, but it is not the ideal long-term security shape. The current architecture forces one broad VMM seccomp profile to cover multiple responsibilities:

- libkrun / core VMM execution
- virtiofs host-side file serving
- networking/helper runtime threads
- other shim-managed runtime work

Because those components share one process-wide filter, any syscall required by one component expands the allowed syscall surface for all of them. PR #846 makes this visible with the xattr family (`getxattr`, `setxattr`, `listxattr`, `removexattr`, including `l*` and `f*` variants).

## Desired direction

Refactor the libkrun/VMM runtime boundary so security policy can be applied at a finer granularity, ideally per process or per narrowly-scoped component. For example:

- Keep the core VMM/libkrun process on the smallest syscall profile it actually needs.
- Run virtiofs/file-serving work behind a separate process boundary with an explicit xattr-capable seccomp profile.
- Keep networking/helper paths on their own profile where possible.
- Avoid one shared process-wide allowlist accumulating every syscall needed by any subsystem.

## Acceptance criteria

- Document the current VMM-process-wide seccomp limitation and why #846 had to allow xattr syscalls there.
- Design a process/component split that supports narrower seccomp profiles.
- Introduce separate seccomp profiles for at least the core VMM and virtiofs/file-serving component.
- Ensure writable virtiofs volumes still work without granting xattr syscalls to unrelated runtime components.
- Add regression coverage showing writable virtiofs metadata operations continue to pass under the narrowed profile.

## Related

- PR #846: allows xattr syscall family in the current VMM seccomp profile to prevent virtiofs writes from SIGSYS-killing the VMM.

Start by tracing the VMM-process-wide seccomp setup and the xattr change described in PR #846. Then map the libkrun/core VMM, virtiofs file-serving, and networking/helper boundaries to design separate process or component profiles. Done means the core profile is narrower, writable virtiofs metadata operations still pass, and regression coverage verifies this without exposing xattrs to unrelated components.

Written by the indexing model from the issue text.