bug(cdk): AgentCore runtime leaks ENIs that block cdk destroy; Memory undeletable while CREATING

### Observed (live, us-east-1, 2026-07-31, ADR-021 P1 verification run)

1. **`cdk destroy` of the agent stack hung >1h40m and ended `DELETE_FAILED`**: two service-managed `agentic_ai` ENIs (AgentCore runtime) remained attached to the platform VPC's private subnets after the runtime resource was deleted, blocking deletion of both private subnets and the runtime SG. The stack had to be left in `DELETE_FAILED` (zero-cost residue: VPC shell, 2 subnets, 1 SG) pending eventual ENI release and a delete retry.
2. **`AWS::BedrockAgentCore::Memory` cannot be deleted while in `CREATING`** — a teardown racing a slow Memory creation wedges.

### Impact

Any operator tearing down a deployment (ephemeral stacks, #72's scheduled cleanup) hits multi-hour destroy times or `DELETE_FAILED` states through no fault of their own.

### Proposal

- Investigate whether AgentCore ENI release can be awaited or forced (custom resource that waits/detaches on stack deletion, similar to VPC-lambda ENI cleanup patterns)
- Guard Memory deletion on reaching a stable state
- At minimum: document the expected destroy latency + retry procedure in the developer guide

Not specific to the Lambda MicroVMs backend — observed on the AgentCore substrate during unrelated verification. Refs #645.

Empieza reproduciendo el comportamiento de teardown de AgentCore en us-east-1 y lee ADR-021, junto con el contexto relacionado en #645. Compara la limpieza de ENI propuesta y la protección contra el borrado de Memory con la corrección mínima documentada; se considera terminado cuando destroy finaliza sin DELETE_FAILED o la guía del desarrollador documenta claramente la latencia esperada y los pasos para reintentar.

Escrito por el modelo de indexación a partir del texto del issue.