fix(s3): stop a re-created bucket from adopting a previous one's objects

[vieiralucas]

Summary

Third of the three gaps #2558 documented as out of scope. A bucket absent from memory can still have a directory in the data path: after /_fakecloud/reset (which clears memory and deliberately leaves the store alone), or after a create or delete that stopped partway. CreateBucket cleared only the sidecars, so a stale objects/ tree survived, and a re-created bucket adopted it: the caller saw an empty bucket, then the previous incarnation's objects came back on the next load.

CreateBucket now clears the whole stored directory for the name, before writing this bucket's own state. Ordering is load-bearing: the clear removes meta.toml, so doing it afterwards would delete the bucket the create just wrote.

That clear would otherwise turn re-creating a name into the thing that destroys recoverable data. The loader skips a bucket whose objects it cannot read (a corrupt object meta, a sidecar with no body) and logs a warning; such a bucket is absent from ListBuckets while its files sit intact on disk, so its name looks free. So the store now records which buckets load refused, and CreateBucket declines those names with BucketAlreadyExists plus a message naming the repair. DeleteBucket is the in-band escape, being the explicitly destructive verb, so a refused name is never permanently stuck.

Deliberately minimal: a load-time refusal set and nothing else. No trash directory, no retention, no background reclaim -- that machinery is what made an earlier attempt at this unstable.

Changes

• crates/fakecloud-persistence/src/s3.rs: S3Store::bucket_state_exists and S3Store::bucket_load_refused (both defaulting to false, so memory-only stores are unaffected). DiskS3Store records refusals during load, keyed on the escaped directory name, starting from empty each load so a repaired bucket stops being refused. delete_bucket clears the refusal only once remove_dir_all actually succeeded -- dropping it on a partial failure would leave the next create free to discard the remains.
• crates/fakecloud-s3/src/service/buckets.rs: the refusal check runs inside the write lock before anything is written; the directory clear precedes the meta write; DeleteBucket gains the escape branch for a refused name (no emptiness check is possible -- the objects are exactly what could not be read -- and no owner check either, since the metadata carrying ownership is what failed, so the warning log records that any account can reach it).

Where the refusal stops

The refusal is deliberately bounded, and two review rounds cut it back:

• It requires the data to still BE there (bucket_state_exists), not just to have been refused at load. Otherwise an operator who removed the directory, without restarting, found the name refused for the rest of the process lifetime and was told to repair something that no longer existed.
• A successful create clears the refusal. It is recorded at load and consulted long afterwards, so once a name holds a bucket that loaded, the refusal has stopped being true. Leaving it behind put a live bucket under a refused name, and from there a second account's DeleteBucket recursively deleted its directory (the memory probe is per-account, so it missed the bucket) and a later /_fakecloud/reset refused the create for data that read fine.
• The clear is skipped when there is no directory. It is a recursive remove running under the global S3 write lock, so an unconditional call put a walk of a possibly huge tree in front of every other S3 request on the one create that needs it, and a stat in front of all the rest.

There is deliberately no API call that discards a refused bucket. An earlier revision of this PR gave DeleteBucket that job, on the reasoning that it is the explicitly destructive verb. It could check neither emptiness (the objects are exactly what could not be read) nor ownership (the metadata carrying it is what failed), which made it a verb that destroys retained data for any caller -- and the Object Lock guard added to contain that probed only the bucket-level object_lock.toml, so it missed per-object retention while wrongly refusing to delete an empty lock-enabled bucket. Removing the directory frees the name with no restart, so the escape was never load-bearing: an operator whose store the loader cannot read is already in the data path. DeleteBucket answers NoSuchBucket for a refused name, agreeing with every read path.

One review finding was declined: making HeadBucket / ListBuckets report a refused name as present, so they agree with the create's 409. There is no AWS analogue for "exists but unreadable", and inventing a status for the read paths is a bigger change than the bug warrants; a head-then-create script fails on the create rather than silently overwriting the data, which is the safe direction. The asymmetry is documented instead.

Test plan

• cargo nextest run -p fakecloud-s3 -p fakecloud-persistence -- 550 pass
• cargo nextest run -p fakecloud-e2e --test s3_persistence --test s3 -- 120 pass (plus --test s3_anonymous_access --test iam_enforcement green on the first revision)
• cargo nextest run -p fakecloud-conformance --test s3 -- 51 pass
• cargo clippy --workspace --all-targets -- -D warnings -- clean

Every new e2e test was verified failing without its fix:

• removing the directory clear fails persistence_create_after_reset_reuses_the_name (the old objects reappear after the restart)
• disabling the refusal fails persistence_recreating_a_load_refused_bucket_is_declined_not_destructive (the create succeeds and keep.txt's body is gone)
• dropping the bucket_state_exists half of the guard fails persistence_removing_a_refused_directory_frees_the_name_without_a_restart
• dropping the refusal clear fails that same test at its later half (the name is still refused after a reset, for a bucket that loaded)

Closes the last of the three follow-ups from #2558 (the other two are #2565 and #2566).