Implement a local-first validation lab for macOS, Linux, and CI

[artemnikitin]

Context

Issue #15 defines manually triggered agent-validation, control-plane-validation, and e2e suites, but starting with cloud infrastructure delays useful runtime feedback and adds cost to every iteration. Most current runtime risks are provider-neutral interactions between the control plane, agents, Firecracker, networking, lifecycle, and storage.

Proposal

Build one local-first Linux validation lab and reuse its artifacts, scenarios, assertions, and diagnostics on macOS, Linux, and CI. Use platform-specific adapters only for the isolated Linux environment: Lima with Apple Virtualization on macOS, native KVM on trusted Linux, and an ephemeral VM or suitable KVM runner where isolation is required.

The initial execution order is:

1. control-plane-validation without KVM on ordinary CI.
2. agent-validation with one real Firecracker node and KVM.
3. Local multi-node e2e with two real agents.
4. AWS/GCP profiles for provider-specific certification.

The suites must remain independently useful; cloud E2E must not be required before the first local validation signal is available.

Initial scope

• Capability probes for OS, architecture, KVM, TAP, networking, and isolation mode.
• Immutable source and artifact provenance for every run.
• Local Git desired state and an S3-compatible state service with contract tests.
• Real Firecracker lifecycle, networking, restart/adoption, removal, convergence, and volume scenarios.
• Multi-node placement, cross-node links, host-port ownership, empty state, stale-node, and status scenarios.
• Deterministic diagnostics, cleanup, cancellation handling, and bounded runtime.
• Reusable commands for local execution and CI workflows.

Relationship to #15

This issue proposes the local-first implementation shape for the three validation suites tracked by #15. Keep #15 as the umbrella for the overall validation-suite contract and provider certification unless the project decides to split those responsibilities further.

Acceptance criteria

• A control-plane validation run provides a provider-neutral signal without cloud credentials or billable infrastructure.
• A real Firecracker agent suite runs on supported macOS and Linux setups when KVM is available, and reports unsupported capability rather than silently using a fake binary.
• Local multi-node scenarios reuse the same definitions and assertions in CI where the runner capability is sufficient.
• AWS/GCP profiles continue to cover provider-only contracts.
• Failed, interrupted, and cancelled runs leave no lab resources behind and retain actionable diagnostics.