release(contract): require canonical UUID text in topic-lineage document coordinates #654

Finding

TopicLineageArtifact is digest-bound and already requires canonical UTC spelling for its knowledge_cutoff, but its sequence_edges[*].predecessor_document_id / successor_document_id validation currently only calls Uuid::parse_str.

The producer emits Uuid::to_string(), while the parser accepts alternate textual representations of the same UUID. That permits two byte-distinct, semantically identical document coordinates to be valid artifact JSON and therefore to receive different artifact SHA-256 identities. This violates the deterministic canonical-serialization requirement of #638 and makes a released scientific-result locator depend on a non-canonical UUID spelling.

Required repair

• add a public source-level RED showing that the canonical hyphenated lowercase UUID spelling is valid while an equivalent alternate UUID spelling is rejected;
• keep the existing UUID semantic parse, then require the source text to equal Uuid::to_string() for both predecessor and successor IDs;
• do not change topic-lineage arithmetic, edge topology, document identity semantics, or the v2 schema shape;
• record the byte-identity rule in the release contract / CHANGELOG and fix(release): bind fail-closed reconstructable topic-lineage results (#638) #639 lineage;
• reacquire exact-head hosted checks and qualifying independent review before any promotion.

This is a canonicalization/reproducibility defect, not a request to normalize caller bytes silently: malformed or noncanonical released artifact bytes must fail closed.

Refs #638 #639.