pool: an archived wake waits for the consumed checkpoint's store delete #464

Waking an archived claim deletes its consumed checkpoint from the store before the wake returns (pool/archive.go, wakeArchived, after commitWake). The client's call waits for that delete.

Cost

On the s3 backend Delete runs these requests in sequence:

1. one LIST of the record's manifests;
2. one GET per manifest generation (usually 1-2) to read its lineage;
3. one DeleteObjects for the labels and lineage markers;
4. one DeleteObjects for meta.json.

That is 4-5 round trips. At 20-30 ms each (modeled, not measured on a real bucket) it adds about 80-150 ms to the wake.

Why it is not changed now

• Small next to the rest of the wake. An archived wake fetches the guest's memory image from the store first: seconds for a 512 MiB guest, and more for larger ones. The delete is roughly 2-5% of the wake, and less as guests grow.
• Ordering already handles a failure. The pre-commit mark keeps a failed delete retryable after the journal update, and the tombstone is dropped only after the delete succeeds.

What would reopen it

A wake-latency target for archived claims, or a measured archived-wake breakdown on a real bucket where the delete is a visible share. The change would then be to delete in the background after the socket is returned, keeping the same mark-then-delete-then-drop-tombstone order.