Recovery checks that duplicate a DB finish gate can turn "billing pending" into a runtime error

Lesson: when a database finish function is already the authority that keeps a runtime claim leased until external reconciliation completes (e.g. provider billing), an in-process recovery step that returns a plain bool "finalized?" should not treat "pending external reconciliation" the same as "persistence failed". If it does, every call that produces a pending-but-correct state raises a runtime error, even though there is nothing local left to persist. Distinguish "nothing for this process to write; external reconciliation pending" (skip; let the DB gate hold the claim) from truly ambiguous states (outcome unknown, possibly connected), which should still fail closed. Limits: this applies only when the authoritative gate independently enforces the same invariant. If no reconciler exists to advance the pending state, claims still sit in cleanup indefinitely. That is a separate gap.

Applies when: a LiveKit/Telnyx call ends with a rejected outbound transfer leg and the runtime reports an outbound usage persistence failure. Keywords: livekit telnyx outbound usage persistence failed sip 403 reconciliation pending recovery