[testcontainers]: Implement container pooling with state reset for faster agent test iterations

Issue: [testcontainers]: Implement container pooling with state reset for faster agent test iterations

Feature: testcontainers
Priority: medium
Labels: testcontainers, performance, medium-priority

Description

Agents running test loops spin up and tear down testcontainers on every iteration. For heavy services (postgres with schema migrations, elasticsearch with seed data), this is 10–30 seconds per iteration. With an agent potentially running 20–50 test iterations per task, that's 5–25 minutes of pure container startup overhead. Implement container pooling with state reset so the container is started once per session and reset between test runs.

Intel driver: NestJS Testcontainers Best Practices (Medium, 2026-04-05) — "Share containers, avoid bad setups. Testcontainers spins up and tears down containers on the fly — this brings integration testing locally." The recommendation is explicit: share containers across tests, don't spin up per-test. For agents running in loops, this matters more than for humans running once.

What

1. Container pool: maintain a pool of warm, ready containers per service type/version
2. State reset: between test runs, reset state via snapshot restore (Firecracker-style CoW) or DB truncation (for postgres)
3. Pool sizing: configurable min/max pool size per service
4. Expiry: containers are recycled after N runs or T minutes to prevent state drift

Why

Agent test loops are not like human test runs. An agent may run 50 iterations of a test cycle in 5 minutes. Container startup cost at human pace (once per session) becomes unacceptable at agent pace (50x per session).

Definition of Done

• daax dev testpool start --services postgres:15,redis:7 starts a pool of warm containers
• Subsequent testcontainers-go / testcontainers-npm calls pull from the pool instead of starting fresh
• State reset between test runs completes in <500ms for postgres (truncate all tables) and <100ms for redis (FLUSHALL)
• Pool miss (all containers in use) falls back gracefully to starting a new container, not failing
• Performance test: 10 sequential test runs with pool should be at least 5x faster than 10 runs without pool
• Pool stats exposed via daax dev testpool status (pool size, hit rate, avg reset time)

No files or tests are named. Start by locating the implementation behind daax dev testpool and the existing testcontainers-go and testcontainers-npm integration points. Done means warm pools, reset and fallback behavior, status output, and the stated performance checks all work.