docs: define policy-driven assurance and EP governance roadmap

[pcvantol]

Coordinated documentation increment

POLICY_GOVERNANCE_AND_EFFECTIVE_PROFILES_V1, companion to Forge #50. Documentation and roadmap only; no implementation or active configuration change.

• EP owns effective admission/validation/assurance/provider policies and operational repair accounting, independently of Forge/Workspace availability.
• Classifies policy versus invariant/configuration/grant/runtime fact/implementation limit, with source-pinned inventory.
• Defines policy change/activation semantics, exact Action/admission snapshot binding, current revocation and owner-scoped API/UX boundaries.
• Captures required review/repair/current-candidate/receipt semantics and the unchanged current maximum of three total repair rounds, without claiming feat: add run quality assurance #100 implementation findings closed.
• Specifies native Forge release planning -> EP explicit version/build/publish execution -> Forge Platform qualified composition.
• Adds scoped EP policy/release DAG and registers it in the canonical roadmap. Rich Workspace UI is not a new first-canary dependency.

Scope and coexistence

Three Markdown files only. Existing #100 assurance and #102 dependency-admission PRs remain untouched; no duplicate executor or policy implementation. No runtime, database, credentials, grants, package versions, CI workflow or test source changes. No merge, install or live canary is requested/executed here.

Hosted documentation validation will be recorded on the exact candidate. The design is PENDING_PR until owning merge and does not imply installed availability. Workspace and Forge Platform companion PR links follow in the coordination record.

[pcvantol]

Coordinated documentation-only increment: Forge #50, EP #103, Workspace #15, Forge Platform #18. Full exact-head, DAG and hosted-validation report: pcvantol/forge#50 (comment) .

This EP head d3242c40e886dcb4e7c66ddb4dd7a4012e475545 has all fetched workflow groups green and separate Owner Authorization SUCCESS. Only three Markdown files changed. Existing #100/#102 code/proposals, CENTRAL, active policies, grants, budgets and installed artifacts remain untouched. No implementation finding is closed by this documentation; no merge/deploy authority or runtime readiness is inferred. Reconcile shared roadmap additions with those owning lanes instead of overwriting their newer files.