fix(ecs): write task payload to S3 instead of 8 KB containerOverrides (#502)

[isadeks]

Summary

Fixes #502 — the ECS/Fargate compute strategy rejected every real task with:

InvalidParameterException: Container Overrides length must be at most 8192

Root cause: ecs-strategy.ts inlined the entire orchestrator payload (incl. the large hydrated_context) into the AGENT_PAYLOAD container-override env var. ECS RunTask caps the total containerOverrides blob at 8192 bytes, so the call failed before the container started. AgentCore is unaffected — it passes the payload in the InvokeAgentRuntime request body, which has no comparable limit. The earlier ECS smoke test (#494, a small Rust cargo check) had a payload that fit under 8 KB, so it didn't surface this.

Fix — pass a pointer, not the payload

Piece	Change
EcsPayloadBucket (new)	Dedicated S3 bucket, mirrors TraceArtifactsBucket: BLOCK_ALL + enforceSSL + S3_MANAGED, 1-day lifecycle TTL. Dedicated (not co-tenant with attachments/traces) so the task role's read is scoped to payloads only.
ecs-strategy	PutObject payload → <task_id>/payload.json; pass AGENT_PAYLOAD_S3_URI in the override; boot command fetches via boto3. Inline AGENT_PAYLOAD kept as fallback (small payloads / no bucket) — no regression. deleteEcsPayload helper.
orchestrate-task finalize	Best-effort deleteEcsPayload for ECS tasks on terminal; the 1-day TTL is the crash backstop.
EcsAgentCluster	Accept payloadBucket, inject ECS_PAYLOAD_BUCKET, grant task role read-only (untrusted repo code must not write/delete; the trusted orchestrator owns write+delete). Session-role-aware.
task-orchestrator	ecsPayloadBucket prop → grantPut + grantDelete; @aws-sdk/client-s3 added to bundling externals.
agent.ts	Updated the commented uncomment-to-enable ECS scaffolding to wire the payload bucket.

Security stance

• ECS task role: read-only on the payload bucket (the container runs untrusted repo code).
• Orchestrator: write + delete (trusted).
• Bucket is private (BLOCK_ALL), TLS-enforced, encrypted; payloads expire in 1 day.

Testing

• New ecs-payload-bucket.test.ts: TTL=1d, SSL-only, block-public, autoDelete.
• ecs-strategy.test.ts: S3 write + AGENT_PAYLOAD_S3_URI pointer (no inline blob); inline fallback when no bucket; boot command fetch-from-S3-with-fallback; deleteEcsPayload delete + best-effort swallow + no-op without bucket.
• ecs-agent-cluster.test.ts: ECS_PAYLOAD_BUCKET env, task role read-only (asserts no s3:Put*/s3:Delete*), omitted when no bucket.
• Full mise run build green (cdk tests + agent + cli + docs + synth + lint).

Live verification (dev, ECS wired)

Deployed to a dev stack with --context compute_type=ecs and fired a real fork task:

• compute_type=ecs, session_id = a real ECS task ARN → RunTask succeeded (the prior tasks died here with InvalidParameterException).
• Payload object written to S3: payload.json = 8455 bytes — above the 8192-byte containerOverrides cap, i.e. exactly the payload that would have failed inline.
• Container log: Using hydrated context from orchestrator, then cloned/branched/ran the build — the agent received and parsed the full payload via the S3 pointer.
• Payload bucket live with the 1-day TTL; orchestrator has s3:PutObject/DeleteObject; ECS task role read-only.

Notes / scope

• ECS remains disabled by default on main (the agent.ts wiring is the existing commented uncomment-to-enable scaffolding). This PR fixes the latent strategy bug + plumbing; it does not flip ECS on. Complementary to fix: two bugs that prevent ECS Fargate from working #494.

Closes #502

🤖 Generated with Claude Code