[P2][TX-02] Reconciliation and global reservations

Programme: #1
Epic: #26

## Objective
Handle ambiguous delivery and concurrent financial/resource commitments safely without pretending arbitrary external systems provide exactly-once semantics.

## Scope
- `NeedsReconciliation` workflow for timeouts/disconnects after possible dispatch.
- Provider-supported idempotency keys where available.
- Read-after-write/provider-state reconciliation and configurable verification strategies.
- Reservation ledger for budgets, quantities and other globally bounded commitments.
- Fresh-precondition checks immediately before commit.
- Compensation proposals for cancellable/reversible external effects.
- Expiry/release of reservations and reconciliation after crash/restart.

## Correctness rules
- Unknown outcome is not failure and not success.
- Never blind-retry a potentially committed purchase/bid/message/delete.
- Compensation is a distinct action with its own current authority and possible failure.

## Acceptance criteria
- [ ] Timeout after possible commit enters `NeedsReconciliation` and does not automatically repeat.
- [ ] Idempotency is used only when the provider contract actually supports it.
- [ ] Active reservations prevent concurrent tasks/devices from exceeding configured budgets/limits.
- [ ] Reconciliation can verify success/failure/unknown through provider state and retain evidence.
- [ ] Crash/restart preserves reservations and unknown outcomes.
- [ ] Compensation requires fresh policy evaluation/approval as configured.

## Dependencies
- TX-01
- CORE-04

**First phase:** P2
**Maturity target:** P4
**Owner:** platform/security

No implementation files or tests are named. Begin with dependencies TX-01 and CORE-04, then map where workflows, provider calls, persistence, and policy decisions are defined. Done means the listed acceptance criteria are covered, including durable reservations and unknown outcomes across restart.

Written by the indexing model from the issue text.