fix(revoke): treat an ambiguous Azure Return failure as uncertain (keep the flag), and refuse the claim when too little Lambda time is left #1529

Problem

When an Azure Return fails in a way that doesn't say whether Azure accepted it (a transport error, a 5xx, or the 3-minute deadline from #1528), the revoke handler still clears the "revocation in flight" flag and tells the user it failed. If Azure did accept it, the user sees a failure on a purchase that was actually refunded, and it keeps showing as active. Azure refuses a second Return, so no refund is paid twice, but the record is wrong until an operator fixes it.

The Azure RI exchange path already treats non-4xx failures as uncertain and tells the user to verify before retrying (internal/api/handler_ri_exchange.go).

Related: on Lambda, the work before the claim (mainly Azure's refund calculation) is bounded only by the function timeout. A slow calculation can leave too little time, and Lambda can then end the invocation partway through the Return.

Proposal (owner decision)

1. For non-4xx Return failures, keep the flag set and answer with an "uncertain, verify before retrying" response, as RI exchange does. Leave the row for the 2h sweep or an operator to reconcile.
2. Before taking the claim, refuse with a retryable error when the remaining invocation time is less than the post-claim budget.

Refs #1527, #1528