test(e2e): bucket suite writes before SeaweedFS accepts a key that BucketAccess already reports Ready #4580

The bucket Chainsaw suite fails now and then with mc alias set rejecting a freshly issued key: "The access key ID you provided does not exist in our records". The BucketAccess for that key is already Ready and its Secret is non-empty, so the key exists on the COSI side while the SeaweedFS S3 gateway does not accept it yet.

Two runs so far, on PRs whose diffs do not touch seaweedfs, COSI, the bucket app or the tests:

• feat(scheduler): set scheduling-class label on mutated pods #2621, fork e2e run 36565103774 (job 109396174094): --- FAIL: chainsaw/bucket-1-capacity, step verify-every-bucket-takes-a-write. cap1 and cap2 passed alias, cp and rm, and cap3 failed on mc alias set. BucketAccess bucket-cap3-admin turned Ready at 14:40:54Z, and the failure came about two seconds later.
• feat(kubevirt)!: drop HotplugVolumes for declarative volume hotplug #4453, run 36480578545 (job 109130131391): --- FAIL: chainsaw/bucket, step verify-s3-access, the same mc error. BucketAccess Ready at 21:23:43Z, failure about 1.3 seconds later.

Both steps are in hack/e2e-chainsaw/bucket/chainsaw-test.yaml (mc alias set at lines 151-152 and 389 on main). The test file has not changed since ac92b6b (2026-09-22).

The mechanism is my reading of the timings. I did not trace it in the seaweedfs or cosi-driver source. Ready on the BucketAccess says the credentials were issued and written to the Secret. It does not say the S3 gateway has loaded them, so anything that uses the key right after Ready can race.

A fix in the test would wait until the gateway accepts the key, for example by retrying mc alias set (or mc ls on the bucket) for a bounded time before the write, in both steps. If the driver is meant to report Ready only once the key is usable, that part belongs in the driver instead.