zat's MST delete left subtree nodes it emptied in place, so verifyCommitDiff returned PrevDataMismatch for valid second commits carrying prevData. With Sync 1.1 proofs enforcing since 0b85d4b, those commits were dropped: the conformance corpus's sync11/commit2-valid control now accepts again ("commit validated") instead of being rejected. websocket moves 0.1.8 -> 0.1.10 to match zat, which aligned on it in v0.3.17; two instances in one module graph fail to compile ("file exists in modules 'build' and 'build0'"). Conformance re-run against the published baseline: 43 of 49 rows unchanged, the five intended reject flips intact, the commit2-valid control restored. One further row moves — drisl/unordered-keys-header flips reject -> accept because zat v0.3.12 accepts RFC 8949 bytewise map key order alongside RFC 7049 length-first, and that header ({op,t}) is valid bytewise. The payload case, whose keys are reversed under either ordering, still rejects. That flip is upstream intent, not a regression, and it moves us toward indigo/rsky/hydrant, which all accept that row.