nvx-rs: plan the shares of run through the export planner #802

Parent: #816.

Problem

#622 asks for one planner that lowers exports and mapping tables for the CLI and for external
orchestrators. #765 makes nvx::host::filesystem (plan and ExportPlan) that planner for the
CLI's sandboxes, the blockless root (nvx::host::instance), and aci_edge_sandboxes, and its docs
call it the planner of every NVX caller.

nvx-rs run, which #704 ported from nvx.py run, does not use it yet. It renders its shares from
its options, as nvx.py run did (extend_shares_and_network in nvx-rs/src/host/cli/run.rs):

• One directory --mount is OpenVMM's --mount. Several shares, or a shared file, are the
  --mount-child children of an aggregate at /run/nvx/shares, named by
  aggregate_child_name(index, target), and a cold boot adds their nvx_share= tokens, which
  mount::aggregate_share_tokens renders. nvx-rs: plan every caller's host exports through one planner #765 keeps that function for run alone.
• It passes its host paths, and its --mount-deny, --mount-allow, and --mount-write paths, to
  OpenVMM as given, and OpenVMM attributes each policy path to the share that holds it. Beyond
  the form of its options, it checks only an aggregate's guest targets
  (validate_run_share_targets).

So run's shares get none of the planner's resolution and checks of host paths, policy paths and
targets, and its nvx_share= tokens, which /init's plain VM path (nvx-hostmount) reads, are not
rendered from a plan's binds.

Proposal

1. Build an ExportRequest from run's --mount values, with explicit guest targets, its policy
   paths, and its owner, and plan it with filesystem::plan.
2. Render OpenVMM's arguments and the nvx_share= tokens from the plan's binds, as
   mount::boot_shares does for a one-shot sandbox, and refuse a bind that the tokens cannot
   express.
3. Remove mount::aggregate_share_tokens, and any other helper that only run then uses.

To settle:

• the guest targets that the plain VM root keeps for itself, which run does not reserve today
  beyond / and an aggregate's /run/nvx/shares;
• the meaning of run's policy paths: OpenVMM attributes each one to the share that holds it,
  while the planner takes each share's own paths;
• the children's names, which a snapshot records: a restore must still name them as its boot did.

Acceptance

• nvx-rs run plans its shares through filesystem::plan, and renders its OpenVMM arguments and
  nvx_share= tokens from the plan's binds; mount::aggregate_share_tokens is gone.
• The CLI goldens (nvx-rs/tests/fixtures/cli.json) change only where intended, as the PR lists.
• nvx.py test-microvm passes its share scenarios (filesystem-shares, filesystem-policy,
  filesystem-comma-paths, filesystem-owner, denied-filesystem-paths, and
  filesystem-snapshot), and the virtio restore probe still passes.
• The docs that call host::filesystem the planner of every NVX caller (nvx-rs/README.md, and
  the module docs of host::filesystem, host::sandbox, and host::sandbox::mount) hold for
  run too.

Follow-up of #765 (#622, A4 PR 4), whose description lists it.