Implement Context Builder authorization and source-access policy

[andrewperis]

Parent epic: #5

Summary

Implement Context Builder authorization and source-access policy for Context Builder v1.

Ownership and dependencies

• Repositories: platform; codex only for reviewed contract gaps.
• Depends on: Define versioned Context Builder request, source and result contracts #76.
• Baseline: Prompt SDK v1.0.0 and Context Package v1.0.0.

Scope and deliverables

• Require an explicit caller/owner, purpose, source scope, target prompt/version, classification ceiling and time-bounded preparation decision before loading source bytes.
• Implement a policy-verifier interface and deterministic test verifier; trusted policy evidence must be verified rather than inferred from a caller-supplied allow string.
• Keep preparation approval distinct from the later exact package-instance use authorization required by Prompt SDK.
• Prevent confused-deputy access, source-scope expansion, expired/revoked decisions, path traversal and authorization-cache reuse across callers/purposes.

Acceptance criteria

• Denied, missing, malformed, expired or mismatched authorization fails before source read, with tests proving no read occurred.
• Authorization is bound to exact scope and target; classifications cannot be downgraded.
• Mock decisions cannot be mistaken for production authority; trust configuration is explicit.
• Diagnostics and audit projections omit credentials, private paths and protected policy evidence.

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.