Missing revert mechanism for pending states allows permanent position lockup on backend failure

When settlePosition is called, the position transitions to SettlePending and all conditional tokens are transferred to the admin for off-chain redemption (L985). If finalizeSettle is never called due to backend crash, key rotation invalidating the pre-signed signature, or operational error, the position is permanently stuck.

No other function accepts SettlePending state. There is no revertSettle, no timeout, and no user-initiated recovery path. The admin holds the tokens (or has already redeemed them for USDC off-chain), and the user has no on-chain recourse.

This contrasts with OpenPending, which has revertOpen (L714) as an escape hatch, itself added as a prior audit fix (MEDIUM-3) to address the same class of issue.

The same structural problem applies to ClosePending and LiquidatePending: both transfer tokens to the admin and rely exclusively on the corresponding finalize* function to resolve the position. If finalization never occurs, the position is stuck and user funds are locked.

Add a revert* escape hatch for each pending state, following the revertOpen precedent:

• revertSettle: returns USDC (or re-credits the position) after a configurable timeout, callable by admin or position owner.
• revertClose / revertLiquidate: similar recovery mechanisms returning tokens to the vault and reverting state to the prior position state.

Each should include a timeout to prevent premature reversion while giving the backend reasonable time to complete the off-chain operation.

Acknowledged. Deferred to a future V2 with partial-fill-aware reverse transitions.