feat(compute): add AWS Lambda MicroVMs as a ComputeStrategy backend

Component

Compute backends (ComputeStrategy), CDK/infra wiring, orchestrator session lifecycle, agent runtime entrypoint, docs (COMPUTE.md)

Describe the feature

ABCA already selects a per-repo compute backend via Blueprint compute.type / compute_type (agentcore default, ecs for Fargate when enabled). Add AWS Lambda MicroVMs as another ComputeStrategy option.

Lambda MicroVMs is a serverless Firecracker-based sandbox primitive with near-instant launch/resume, state persistence across interactions (up to ~8 hours), suspend-when-idle (no compute charge while suspended), dedicated URL + JWE auth, and vertical scale up to 4× baseline. AWS positions it explicitly for AI coding assistants and agent sandboxes — a strong fit for ABCA’s isolated, unattended coding sessions.

This is not classic Lambda (15-minute cap). COMPUTE.md correctly marks traditional Lambda as a poor fit; Lambda MicroVMs should be evaluated as a distinct row/backend.

Use case

• Operators want VM-level isolation and suspend/resume economics without operating ECS clusters or depending solely on Bedrock AgentCore Runtime constraints (e.g. 2 GB image limit).
• Multi-step agent tasks that idle on approvals or long builds benefit from suspend/resume and retained memory/disk state rather than always-on Fargate tasks.
• Multi-tenant sandbox patterns (dedicated endpoint per session, strong isolation) map cleanly onto ABCA’s one-session-per-task model.

Context

• Existing backends: AgentCore Runtime (Firecracker MicroVM, managed) and ECS on Fargate (ecs-strategy), selected through the orchestrator’s strategy interface (ORCHESTRATOR.md, COMPUTE.md).
• Liveness differs by backend today (AgentCore heartbeats//ping vs ECS DescribeTasks) — a MicroVM strategy needs an explicit poll/stop/suspend model (#491).
• Related substrate-portable work: #641 (AgentCore Gateway across substrates), #596 (ECS Fargate usability).
• Product overview: https://aws.amazon.com/lambda/lambda-microvms/

Proposed solution

RFC + spike, then implement behind Blueprint config:

1. Capability matrix — Compare Lambda MicroVMs vs AgentCore vs ECS for: max duration, image/rootfs packaging, network/VPC/egress, IAM, auth to the sandbox endpoint (JWE), suspend/resume hooks, observability, regional availability, and pricing dimensions (compute, snapshot, data transfer).
2. ComputeStrategy implementation — e.g. compute.type: 'lambda-microvm' with startSession / pollSession / stopSession (and likely suspendSession / resumeSession) wired like agentcore-strategy / ecs-strategy.
3. Packaging — Define how the ABCA agent image/rootfs is built and loaded into a MicroVM; keep parity with agent contract (clone → edit → verify → PR) and progress events.
4. Orchestrator integration — Session sticky routing, idle/suspend policy, failure classification, and cost/attribution tags consistent with other backends.
5. Infra — CDK (and later any Terraform path) constructs, bootstrap ComputeTypes inclusion, IAM least privilege for MicroVM APIs.
6. Docs — Update COMPUTE.md comparison table; document when to choose MicroVMs vs AgentCore vs ECS.

Acceptance criteria

• ADR/RFC captures fit, non-goals, and API/lifecycle mapping for Lambda MicroVMs.
• Blueprint can select lambda-microvm (name TBD) per repo; default remains agentcore.
• Orchestrator can start, poll/liveness-check, suspend/resume (if exposed), and terminate a task session on MicroVMs.
• Agent completes a smoke coding task (clone → change → PR) on the MicroVM backend with progress visible to bgagent watch.
• Egress, secrets, and session isolation meet the same security bar documented for other backends (or explicitly list deltas).
• Bootstrap/IAM and docs cover enabling the backend; CDK tests cover strategy wiring.
• COMPUTE.md distinguishes Lambda MicroVMs from classic Lambda.

Out of scope (initially)

• Replacing AgentCore as the default backend.
• Using classic Lambda functions (15-minute) as the agent runtime.
• GPU / exotic device passthrough unless MicroVMs GA features clearly support them.
• Full feature parity with every AgentCore-only managed integration on day one (track follow-ups; prefer substrate-portable Gateway/Identity paths where possible).

Tests

• Unit tests for the new strategy (start/poll/stop/suspend mapping, error classification).
• CDK assertions for optional MicroVM resources when ComputeTypes includes the new backend.
• Agent/orchestrator integ or smoke gated similarly to ECS backend work.
• Docs sync for design guide updates.