evidence: give source observation and availability records stable owner identities #530

Finding

#527 now prevents caller-selected source availability and keeps arbitrary receipt JSON distinct from owner-issued Evidence state. A remaining lineage gap is that the two owner records that establish that trust path are not themselves addressable records.

SourceObservation currently binds SourceArtifact identity + source digest + SystemTime, but has no observation/event identity. SourceAvailability copies the artifact identity/digest/observation time and adds AvailableTime, but has neither its own identity nor the identity of the exact observation from which it was derived. SourceSnapshotReceiptV1 therefore commits the source artifact/content and two clocks, but cannot point to the exact Evidence-owned observation and availability records that authorized those clocks.

Repeated observation/availability of the same immutable source is scientifically and operationally legitimate. Timestamps are attributes, not record identities; they should not be used as a surrogate key for lineage, audit, replay, recovery, or later repository persistence.

Required RED

Through the public Evidence API:

1. observe the same immutable SourceArtifact twice and require two distinct canonical Evidence identities while content/artifact identity remains the same;
2. create availability from each observation and require each availability record to have its own distinct identity and to retain the exact owning observation identity;
3. mint a source-snapshot receipt and require the canonical receipt/binding to preserve both owner-record identities in addition to source-artifact identity/content digest and the two nominal clocks.

The RED must not use private field mutation, timestamps as surrogate identities, or caller-supplied UUIDs.

Minimal causal repair

Make SourceObservation and SourceAvailability first-class Evidence entities by minting UUIDv7 EvidenceId values inside the Evidence bounded context. SourceAvailability must retain source_observation_id; SourceSnapshotReceiptV1 must bind source_observation_id and source_availability_id and validate them as canonical Evidence IDs on wire import.

Keep these identities separate from:

• source_artifact_id;
• source_snapshot_sha256;
• logical snapshot_id;
• receipt identity/binding digest;
• Rubin estimator_payload_sha256.

Do not claim signatures, external authenticity, chain of custody, or repository persistence merely because the owner records are now addressable.

Acceptance

• production callers cannot select observation/availability IDs;
• repeated observation/availability of identical source bytes produces distinct owner-record identities without changing source-artifact/content identity;
• availability binds the exact source-observation identity it follows;
• receipt canonical JSON and binding digest include both owner-record identities;
• malformed/noncanonical owner-record IDs fail closed on wire validation;
• existing SystemTime/AvailableTime ordering and no-public-wire-to-owner promotion boundary remain intact;
• exact-head Rust format/lint/test/rustdoc, authored line/branch coverage, repository/PostgreSQL/security checks and qualifying independent review remain required before feat(evidence): own immutable source snapshot receipts #527 can land.