[Task]: Harden governance version resolution semantics

[rian-be]

Summary

Tighten the semantics of stale request and revalidation handling in the governance runtime.

Goal

Make version resolution durable execution contract with explicit behavior for revalidation, renewed approval, and stale rejection paths.

Problem

Version resolution exists today, but its semantics needed hardening before governed execution could become a stable contract:

• RevalidateOnLatestState needed sharper operational meaning
• revalidation needed explicit runtime semantics
• request history needed to make resolution outcomes obvious

Scope

• Clarify the operational meaning of RevalidateOnLatestState
• Consider a dedicated pending reason or status path for revalidation
• Ensure approved requests always resolve version state before execution
• Add end to end scenarios for stale approval renewal and re-execution
• Expose resolution outcomes consistently through request decisions, examples, and tests

Design Expectations

• Version resolution should remain deterministic and auditable.
• Revalidation should be runtime concept, not just a vague branch name.
• Renewed approval should be clearly distinguishable from stale rejection and plain execution.
• Examples should make the semantic differences observable without reading internal code first.

Acceptance Criteria

• Revalidation semantics are explicit and documented
• Stale approval flows are covered by end to end tests
• Resolution outcomes are auditable and visible in request history
• Renewed approval and stale rejection paths are distinct runtime behaviors

Non-Goals

• This issue does not add governed execution orchestration by itself
• This issue does not add persistence providers
• This issue does not introduce compensation semantics

Notes

Version resolution exists today, but its branch semantics needed hardening before governed execution could become a stable contract.