Sandbox: support symlink creation in rw virtio-fs workspace shares #296

Part of #290 (requirement 5).

Summary

Building ordinary projects in a live workspace needs symlinks to work. Examples: npm ci creates .bin symlinks, and Go, Rust, and Python virtualenvs create symlinks too. Today, creating a symlink on the microVM virtio-fs profile returns ENOTSUP.

Current state

In OpenVMM, vm/devices/virtio/virtiofs/src/microvm/fs.rs check_symlink_allowed() returns ENOTSUP whenever is_microvm() is true. Snapshot saved state also rejects symlink identities (saved symlink identities are unsupported by the microVM profile).

Work

• OpenVMM (nanvix/openvmm): allow symlink() on writable microVM shares and store the target exactly as given. Keep every host path lookup safe: use strict O_NOFOLLOW traversal so a guest-created link can never be followed outside the export root, and keep denied paths enforced through links. Decide on Windows/WHP behavior (for example WSL-style symlinks via the existing lxutil path, or a documented rejection). Extend saved-state handling to cover symlink inodes.
• NVX: promote the OpenVMM pin, then update the documentation and the sandbox live-share CI smoke test.

Acceptance criteria

• Creating a symlink in a rw workspace share succeeds, and the target is preserved exactly.
• A symlink whose target points outside the export root, or into a denied path, cannot be used to read or write host data outside the policy.
• Creating a symlink in a ro share is still rejected.
• npm ci (or a similar workload that creates .bin symlinks) works in a live rw workspace in CI.