Receive cancel()

[spacebear21]

This implements a generic cancel() method on the Receiver, following up on discussion from #1134.

As discussed on the PR review club a few weeks ago, this implementation of cancel() returns the fallback transaction as a convenience and a "hint" to broadcast it if it hasn't already been. Doing this adds quite a bit of complexity due to having to implement a fallback_tx getter for every concrete typestate, some of which return None. IMO the ergonomics are probably worth the cost of this internal ugliness, but I'm curious what other people think.

The existing flow is for implementers to call extract_tx_to_schedule_broadcast after the broadcast suitability check passes and store that somewhere for broadcasting later, or to replay events and use SessionHistory::fallback_tx to access it for broadcasting. This PR introduces a third accessor for the same data. Is there still a need for the other two getters if we aim to encourage cancel()ing?

Supersedes #1134.

Authored with Claude - who incidentally has learned to generate all downstream language bindings and run their tests in parallel in the background while doing other things.

Pull Request Checklist

Please confirm the following before requesting review:

• I have disclosed my use of
  AI
  in the body of this PR.
• I have read CONTRIBUTING.md and rebased my branch to produce hygienic commits.

[coveralls]

Coverage Report for CI Build 24111378470

Coverage decreased (-0.2%) to 84.144%

Details

• Coverage decreased (-0.2%) from the base build.
• Patch coverage: 36 uncovered changes across 2 files (33 of 69 lines covered, 47.83%).
• No coverage regressions found.

Uncovered Changes

File	Changed	Covered	%
payjoin/src/core/receive/v2/mod.rs	53	26	49.06%
payjoin/src/core/persist.rs	16	7	43.75%

Coverage Regressions

No coverage regressions found.

---

Coverage Stats

Relevant Lines:	12872
Covered Lines:	10831
Line Coverage:	84.14%
Coverage Strength:	410.2 hits per line

---

💛 - Coveralls

[DanGould]

soft/draft ACK 3f2e13e assuming mutants issues can be explained. This design is simple to understand. Draft just because it's not yet in payjoin-cli? I don't think we'll be able to confidently answer whether the ergonomics of this are correct nor if the other accessors can be deleted until the reference implementation adopts it. Not sure if that looks like #1164 or your own implementation in this PR. But I have a strong hunch this is the right direction and am comfortable even merging before we have such confidence because so much discussion around this already landed on this design.

---

Reviewing per the discussion in #1470

does cancel():

• immediately close the session with SessionOutcome(Cancel)
• return the fallback transaction to broadcast.

Ya you have tests for these