fix(revoke): record an accepted Azure Return even if the request is canceled right after it #1525

Problem

After Azure accepts a Return, the revoke handler records it (MarkRevocationReturnPosted, from #1524) and marks the purchase revoked using the request's context. If the request is canceled right after the Return (client disconnect, Lambda timeout), or the database is unavailable for the whole retry window, nothing is recorded. The sweep then clears the flag after 2h, and the purchase shows as active even though Azure refunded it. An operator has to fix it from the error log. Azure refuses a second Return, so there is no double refund, but the record is wrong.

Proposal

Run the writes that follow an accepted Return with a context that ignores request cancellation (context.WithoutCancel) and has its own bounded timeout. The retries stay as they are. Also correct #1524's comment that 2h is "twice the longest request any deployment can run": Fargate and Container Apps don't bound request time. Correctness doesn't depend on it, but the claim shouldn't be wrong.

Acceptance criteria

• A test where the request context is canceled immediately after the Return is accepted still ends with the Return recorded and the purchase marked revoked.
• No write before the Return ignores cancellation.

Refs #1523, #1524