Scope and rotate the AWS CI credential; delete the dormant access key

## Summary

Two follow-ups on the AWS CI credential, found while verifying the IAM prerequisite for #4298 (the AWS test-resource cleanup sweep). Neither blocks that PR — the sweep's permissions are already in place. Both are housekeeping on the credential itself.

Specifics (account id, IAM user, key ids) are deliberately left out of this public issue; a maintainer with console access will find them immediately.

### 1. The CI access key is far broader than CI needs

The key behind the `AWS_ACCESS_KEY_ID` / `AWS_SECRET_ACCESS_KEY` secrets carries `AdministratorAccess`. The four AWS-backed CI jobs need a small, enumerable slice of that:

| Job | Services |
|---|---|
| `dynamodb-ci` | DynamoDB |
| `aws-ci` | SNS, SQS, S3 |
| `aws-scheduler-ci` | EventBridge Scheduler (plus SNS/SQS targets) |
| `aws-cleanup` (sweep) | SNS, SQS, EventBridge Scheduler, Resource Groups Tagging |

The sweep's own requirement is fully known, since every call it makes is in `clean_failed_tests_aws_assets.sh`:

```
tag:GetResources
sns:ListTopics sns:ListTagsForResource sns:TagResource
sns:DeleteTopic sns:Unsubscribe sns:ListSubscriptionsByTopic
sqs:ListQueues sqs:GetQueueUrl sqs:GetQueueAttributes sqs:DeleteQueue
scheduler:ListSchedules scheduler:GetScheduleGroup
scheduler:DeleteSchedule scheduler:DeleteScheduleGroup
```

The test suites' requirement is the wider and less certain half — they create as well as delete, across five services. Scoping the key without enumerating that first will break CI, so the work is:

- [ ] Enumerate what the four jobs actually call (CloudTrail over a week of CI runs is the cheap way; `iam simulate-principal-policy` confirms a candidate policy before it is attached)
- [ ] Write a scoped policy and attach it to a **new** key
- [ ] Cut CI over to the new key, confirm all four jobs green, then deactivate the old one

Rotation is worth doing on the same pass: the current key predates any rotation practice here by several years.

Beyond the general principle, this is also what makes the class of problem in #4298 structurally impossible to recur. That PR's topic age-guard needs `sns:TagResource` and `sns:ListTagsForResource`; had they been missing, the sweep would have reported "nothing to clean" when it meant "cannot clean". A policy written against a known action list is checkable in CI; a blanket grant is only ever checkable by accident.

### 2. A dormant admin key is still active

The user has a second access key, last used in January 2019, still `Active` and carrying the same administrator rights. Nothing references it.

- [ ] Deactivate it, confirm nothing breaks, then delete it

This one is independent of item 1 and costs nothing — worth doing first.

## Notes

- The repo has no `SECURITY.md` and no private vulnerability reporting, so there was no private channel to raise this in. Worth adding one regardless.
- Secret scanning and push protection are already enabled on the repo, so the risk here is scope and age, not exposure.