Enforce invoice-scoped accounting-bridge mutations

[ValeraFinebits]

Problem

PayjoinSessionBuildLock fixes the session-recreation race in PR #76, but other accounting-bridge writes still rely on implicit call-site discipline.

A session for invoice A can still continue running after invoice A has been recreated and write fallback, settlement, or final-transaction data from an old session. Reconciliation can also act on stale bridge snapshots after retry, expiry, recreation, or finalization.

Goal

Make invoice-scoped bridge mutation explicit and safe:

• require a typed, invoice-bound lease for in-process bridge mutations;
• add persisted incarnation / revision checks so stale writes are rejected across retries and restarts;
• ensure reconciliation and retry use compare-and-set style validation against the bridge snapshot they started from;
• keep operations for different invoices independent and parallel.

In scope

• fallback attachment and settlement-output persistence;
• proposal finalization and replay;
• receiver event persistence;
• bridge creation, reset, retry, expiry, reconciliation, and failure;
• session recreation and stale-write rejection.

Acceptance criteria

• No bridge mutation can occur without an explicit invoice-lease contract.
• Session-A writes cannot overwrite session B after recreation.
• Obsolete reconciliation results cannot mark the current bridge reconciled or failed.
• Cross-process stale writes are rejected by database validation.
• Holding one invoice lease does not block another invoice.
• Existing lifecycle and crash-retry tests continue to pass.
• Lease scope, session incarnation, bridge revision, and process-local limitations are documented in XML docs.

After PR #76

Implement this as a follow-up PR after PR #76 is merged, using the current reset/recreation flow as the base to extend with lease propagation and stale-write protection.