[1/4 Add AWS integration layer

[ericc59]

Summary

Adds foundational AWS integration components for distributed benchmark execution:

• DynamoDBProgressManager: Distributed task coordination with atomic claim/complete/fail operations, FAILED_PERMANENT status for exhausted retries, run-level cost/token aggregate rollups
• DistributedRateLimiter: DynamoDB-backed token bucket with rate/period interface matching provider_config.yml, exponential backoff on contention
• ExecutionContext: Environment detection for LOCAL/EC2/FARGATE/BATCH (handles IMDSv2 401/403 responses)
• Dependencies: boto3 moved to [aws] extras, moto to [test] extras

Part of

This is PR 1/3 for AWS distributed execution:

1. This PR: AWS integration layer
2. Batch worker + Dockerfile (depends on 1)
3. Lambda functions (depends on 1)

Test plan

• All 20 AWS integration tests pass
• Manual verification with mocked DynamoDB

[hlfshell]

I could be missing something here, but - we lock the task in claim_task to prevent it from being worked on, and use a conditional update to prevent a race condition - this is a great pattern. But I don't see anywhere that we update the status of this reserved task at a routine update time, forming a watchdog timer pattern. Without this, it's possible for tasks to be claimed, our daemon process to die, and the tasks to never be unlocked.

get_pending_task correctly filters for PENDING and FAILED, but not IN_PROGRESS paired with a "last updated" timeout, which would get around this. If we were not confident in the execution time of our daemonized process, we would have to do the watchdog timer pattern; otherwise we can get away with a simple "if IN_PROGRESS and hasn't been updated in 15 minutes" approach to that query to catch these stray tasks.

...I could just be missing a task timeout somewhere too.

[ericc59]

I could be missing something here, but - we lock the task in claim_task to prevent it from being worked on, and use a conditional update to prevent a race condition - this is a great pattern. But I don't see anywhere that we update the status of this reserved task at a routine update time, forming a watchdog timer pattern. Without this, it's possible for tasks to be claimed, our daemon process to die, and the tasks to never be unlocked.

get_pending_task correctly filters for PENDING and FAILED, but not IN_PROGRESS paired with a "last updated" timeout, which would get around this. If we were not confident in the execution time of our daemonized process, we would have to do the watchdog timer pattern; otherwise we can get away with a simple "if IN_PROGRESS and hasn't been updated in 15 minutes" approach to that query to catch these stray tasks.

...I could just be missing a task timeout somewhere too.

Good catch. Pushed a commit to address that.