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](https://aws.amazon.com/lambda/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](https://github.com/aws-samples/sample-autonomous-cloud-coding-agents/blob/main/docs/design/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](https://github.com/aws-samples/sample-autonomous-cloud-coding-agents/blob/main/docs/design/ORCHESTRATOR.md), [COMPUTE.md](https://github.com/aws-samples/sample-autonomous-cloud-coding-agents/blob/main/docs/design/COMPUTE.md)).
- Liveness differs by backend today (AgentCore heartbeats/`/ping` vs ECS `DescribeTasks`) — a MicroVM strategy needs an explicit poll/stop/suspend model ([#491](https://github.com/aws-samples/sample-autonomous-cloud-coding-agents/issues/491)).
- Related substrate-portable work: [#641](https://github.com/aws-samples/sample-autonomous-cloud-coding-agents/issues/641) (AgentCore Gateway across substrates), [#596](https://github.com/aws-samples/sample-autonomous-cloud-coding-agents/pull/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.