fix(storage): reject unusable erasure metadata at every sink

Malformed erasure layouts can divide by zero, while negative part sizes collapse expected shard sizes to zero and make truncated data appear healthy. Boundary validation alone is insufficient because poisoned metadata may already exist on disk or arrive through local heal paths.

Reject non-positive block sizes at the sole Erasure constructor, guard the metadata arithmetic helpers and rebalance calculation, refuse negative part sizes before persistence, and make CheckParts and VerifyFile reject previously stored poison. Tests cover both shard-size implementations, construction, persistence, local verification, and the wire boundary.

Co-authored-by: ChatGPT <noreply@openai.com>
Co-authored-by: Claude <noreply@anthropic.com>

cmd/xl-storage-format-v2.go

@@ -1590,6 +1590,13 @@ func (x *xlMetaV2) UpdateObjectVersion(fi FileInfo) error {
 
 // AddVersion adds a new version
 func (x *xlMetaV2) AddVersion(fi FileInfo) error {
+	// Refuse to persist metadata no shard size can be derived from. This is the
+	// single funnel every version write passes through, so rejecting here keeps
+	// the poison off disk rather than relying on every reader to cope with it.
+	if fi.HasNegativePartSize() {
+		return errFileCorrupt
+	}
+
 	if fi.VersionID == "" {
 		// this means versioning is not yet
 		// enabled or suspend i.e all versions