max / makenotwork

s3-storage: soak target over multipart part geometry Row 7 of astra-soak-overview, the upload and object path. The doors were counted first, as infra 8910f917 instructs, and the count decided the shape: almost all of the crate is async I/O against a live endpoint and is not fuzzable without one, while MultipartPlan is pure arithmetic with four call sites in the server and one implementation behind them. The oracle lives in the crate, following git-command's precedent, so the libFuzzer target on nightly and tests/regressions.rs on stable assert the same things and cannot drift into checking less than each other. It asserts that the parts tile the object exactly (a gap loses bytes, an overlap duplicates them, and neither shows until playback), that S3's own limits hold, that out-of-range part numbers are refused rather than answered, and that every rejection names a condition that actually does hold, which is what protects a legitimate upload from being turned away. SyncKit's client check is a one-line div_ceil restatement rather than a second parser, so this asserts the property instead of running a differential against it. Fifteen seeds at the boundaries where part arithmetic goes wrong, plus the off-by-one either side of each; regressions/ replays as an ordinary cargo test so a crash found on astra cannot come back unnoticed here. Not yet registered in witchbroom.toml, so the soak half of 8910f917's done condition is still open, as is the mutation half (1498fe2a).