Define versioned Context Builder request, source and result contracts

[andrewperis]

Parent epic: #5

Summary

Define versioned Context Builder request, source and result contracts for Context Builder v1.

Ownership and dependencies

• Repositories: codex; coordinated platform consumer.
• Depends on: Define Context Builder v1 architecture and responsibility boundaries #75.
• Baseline: Prompt SDK v1.0.0 and Context Package v1.0.0.

Scope and deliverables

• Specify explicit build intent, target prompt/version and declared slots, approved source references, evaluation time, selection policy, ordering, budgets and builder identity.
• Define normalized source/candidate evidence, result/failure and machine-readable diagnostics, including exact lineage and reason codes.
• Reuse immutable Context Package v1 output and authorization semantics; identify versioned additions only where needed. Never mutate released v1 bytes.
• Define unknown-field/version behavior, compatibility, canonical identity, classification, empty/missing required context and conflict semantics.

Acceptance criteria

• RFC/specifications and closed schemas agree, with synthetic valid/invalid fixtures.
• Successful output can be consumed by released Prompt SDK v1 or has an explicit reviewed migration plan.
• Determinism inputs, required versus optional slots, budget units and failure states are unambiguous.
• Private evidence identifiers are opaque; public schemas/examples contain no protected source details.

Implementation guardrails

Follow Constitution v1.0.0 at a9cc8a503aa30e17820edc62ac95f7cbe10e0564 and repository boundaries. Add focused tests with implementation; the later suite task consolidates rather than postpones testing. Public issues, fixtures and docs use synthetic/already-public material only. Approved private inputs stay behind explicit secure artifact boundaries. No direct Lore checkout, silent declassification, self-approval or canon promotion.