feat: add a principal-scoped Linux Realm capsule

Summary

Add Linux Realm as a principal-scoped AOS capsule: a persistent, suspendable Linux developer workbench that gives an agent familiar shell and toolchain semantics without granting the capsule ambient host-process access.

The capsule boots a reproducible RISC-V Linux image inside Astrid's generic compute boundary, projects the authenticated invocation workspace at /workspace, persists the principal's Linux home independently, and exposes a normal foreground shell tool.

Motivation

Agents are trained to use Linux shells, compilers, package/tool ecosystems, and conventional project layouts. Reimplementing that entire environment as individual host functions would be incomplete and would enlarge Astrid's privileged surface.

Linux Realm should instead make Linux an ordinary governed capsule workload:

• one logical realm per Astrid principal;
• near-instant warm command execution after initial restore;
• a durable principal home and an invocation-scoped workspace;
• Rust, Git, build tools, and other agent workbench essentials inside the guest;
• multiple virtual CPUs through signed generic compute workers;
• CPU, memory, storage, fuel, and lifecycle governed by principal/operator policy;
• no direct host process execution and no guest GPU/device access unless a future explicit capability provides it.

Proposed implementation

• Implement a bounded RISC-V machine, privileged execution, Sv39 translation, virtual SMP, timers, block transport, and 9P-style workspace/home plumbing in Rust.
• Boot a pinned Linux kernel and reproducible Buildroot-based userland with a minimal agent development toolchain.
• Package immutable kernel, rootfs, prewarm checkpoint, and signed vCPU worker assets into the capsule.
• Restore a prewarmed machine once per compatible image/runtime identity and keep principal realms resident between foreground calls.
• Expose realm_shell as the agent-facing foreground surface, with multiline streaming and ordinary stdout/stderr semantics.
• Mount the host-stamped invocation workspace at /workspace; keep the guest's principal home durable through AOS storage.
• Derive memory and vCPU admission from Astrid principal compute policy rather than capsule-local arbitrary ceilings.
• Record reproducible performance evidence and security/lifecycle design alongside the implementation.

Security invariants

• The capsule declares no host-process capability; guest-built files remain host data and cannot execute natively without a separate privileged promotion boundary.
• Workspace authority comes only from the authenticated host attachment, not a model-supplied path argument.
• Realm state, home, worker groups, and accounting are principal-bound.
• Guest symlinks, path traversal, malformed 9P operations, stale handles, and disconnect/reconnect paths fail closed at the host VFS boundary.
• Worker binaries and machine assets are pinned and signed.
• Background work requires an explicit lifecycle operation; foreground shell execution ends with the tool result.

Acceptance criteria

• A capsule artifact builds from pinned inputs and installs on current AOS/Astrid.
• Cold boot, prewarm restore, and warm command timings are recorded reproducibly.
• /workspace reflects the invoking agent's current workspace and guest pwd starts there.
• Principal home survives later invocations while another principal receives isolated state.
• Multiline shell scripts, Git, C, and Rust compilation work inside the guest.
• vCPU and memory requests are policy-derived and support host-appropriate defaults.
• Adversarial filesystem, symlink, malformed-message, stale-state, and resource-accounting tests pass.
• Licensing/source lockfiles and redistributable guest artifacts are included.

Dependencies

Depends on the Astrid runtime issue/PR that adds generic principal-scoped compute workers and authenticated workspace attachments.

Alternatives considered

• WASI as the developer environment: rejected for now because AOS capsules intentionally target wasm32-unknown-unknown and audited astrid:* imports rather than adopting a second ambient syscall engine.
• QEMU or Docker as the production runtime: useful as build/reference tools, but they do not provide the desired capsule-native, principal-metered boundary or warm-turn latency.
• Direct host shell execution: rejected because it collapses the security boundary.
• A large general-purpose distro image: deferred; the initial image should stay minimal, reproducible, and purpose-built for agent development.