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.

Commencez par reproduire le comportement de teardown de AgentCore dans us-east-1 et lisez ADR-021, ainsi que le contexte associé dans #645. Comparez le nettoyage d’ENI proposé et la protection contre la suppression de Memory avec le correctif minimal documenté ; c’est terminé lorsque destroy s’achève sans DELETE_FAILED, ou que le guide du développeur documente clairement la latence attendue et les étapes de nouvelle tentative.