test: verify a bucket migrated to the tenant-rooted layout #1870

[DmytroZaichenkoDev]

Stacked on #1892.

Copies a legacy tree into the tenant-rooted layout, checks everything arrived, then boots a tenant-rooted core onto the copy with an empty cache and reads it all back.

The only instrument that crosses layouts. The other two start empty and each run reads only its own writes, so neither can see a failure that happens only to data written under one layout and read under the other — which is the whole of what P2 is about to do.

What it compares:

Inventory	every source path, mapped through the transform, exists at the destination; nothing extra
Content	the bytes
Metadata	content-encoding, content-type, etag, author, created_at
public/rules/rules	by name, not as a row in a count — its absence fails open, and every object count would still add up
Read-back	what each resource returned before the move vs after

Read-back is a before/after comparison rather than an assertion of 200: the question is whether migration changed anything, not whether every fixture happens to be readable.

BucketCopier is a stand-in for the migrator P2 will build, not that migrator. It exists so the verifier has something to verify, and so the questions the verifier asks are settled before the real one lands. Swap it when P2 arrives.

What building it turned up: a byte-perfect copy still produces an unreadable bucket. Whether an object is compressed is recorded beside it rather than inside it, along with its etag, author and creation time — so a copy that keeps every byte and drops the metadata reads back as a parse error. Only some resources are affected, since small ones are stored uncompressed, which is what makes it easy to miss.

Inventory and checksums both passed while that was true. That is why the verifier compares metadata as well, and it is the thing P2's migrator most needs to get right.

🤖 Generated with Claude Code