fix(operation): reject stale executor revisions before durable proposal and preserve delivery blockers #4366

Problem

A live, simulation-only Goal Channel qualification exposed two control-plane gaps before any real finance execution:

1. prepare-operation --execute accepts and persists a proposal whose requested executor revision does not match the active extension revision. deliver-operation rejects it later, leaving an unreachable gated proposal without a card.
2. The Goal Channel CLI catches stage-specific ValueErrors and projects them as broad invalid_configuration / provider_api_failed blockers. In the same run, an actual Feishu Card 2.0 schema rejection (API 200621) was not distinguishable from binding drift, identity failure, or history-read failure.

This is domain-neutral operation lifecycle and receipt behavior. It must not special-case finance or Lark card fields.

Acceptance

• prepare-operation resolves the declared executor capability/protocol/permission and checks the active revision in preview and execute modes before writing a durable proposal.
• A revision mismatch returns a stable typed blocker and writes no proposal/idempotency entry.
• deliver-operation preserves typed, public-safe failure stages for executor drift, sender identity verification, dedupe history read, provider rejection, and exact readback failure.
• Receipts do not claim external_write_performed=false when the provider outcome is actually unknown; known-locator recovery remains owned by the existing M3 slice.
• Repeated calls remain idempotent and do not create duplicate cards or rerun an executor.
• Tests cover stale revision before persistence, provider schema rejection before locator, known locator/readback failure handoff, and public-safe error projection.

Scope boundary

Do not fold in Todo/lease semantics, provider promotion, unknown-locator resend policy, or any finance-specific execution authority. LIHUA919 continues to own the independent M3 known-locator readback/receipt recovery slice.