rfc: compose custody receipts with anchored evidence

[DmitrL-dev]

Purpose and scope

This is the custody-specific follow-up discussed in OpenSecureAIAlliance/RFCs#27, intended for the rfc-anchored-evidence branch behind upstream PR #18.

It preserves the original custody commit 164e36ebeac806e9f39b01c22e0771e87a55f280 and the anchoring base 74785a74f8f18470bd307792b1d301a19512a087 as ancestors, including original authorship and DCO history.

• Adds the custody profile and its original three-line SAFE integration.
• Adds reciprocal links between the custody and anchoring profiles.
• Makes temporal anchoring, statuses, producer-basis semantics and their limits remain owned by the anchoring proposal; the custody profile consumes its results without a second mechanism or classification.
• Adds three conformance descriptions: accepted but unanchored; anchored without receiver acceptance; and an anchored transformed output without a transformation receipt.
• Keeps a receipt and the payload it references distinct for anchoring purposes.

This transfer does not revise the number-domain policy, producer-basis taxonomy or anchoring algorithm. Those discussions remain separate.

Verification

Document and Git-lineage checks passed on final commit 36fec4dee4b95762367d02a65984fcdc221aff3d:

• The nine original behavioral requirements and eight original conformance descriptions remain byte-identical; eleven scenarios are now described.
• The original SAFE integration remains byte-identical to the custody contribution.
• The additional integration changes are additions only; all three relative links resolve.
• Both source commits remain ancestors; every added commit has an author-matching DCO trailer.
• The complete diff changes only the three RFC documents; git diff --check passes and the working tree is clean.

These are document/lineage checks, not a claim that an implementation has passed the described runtime scenarios.

Integration boundary

This PR targets the contributor branch backing upstream OpenSecureAIAlliance#18, not the upstream main branch. Upstream OpenSecureAIAlliance#27 remains open until this material is actually incorporated into OpenSecureAIAlliance#18 and its preservation is verified. Opening this follow-up is not itself completion of that consolidation.