Expose fail() and cancel() on Receiver session

[spacebear21]

This gives implementers the ability to manually fail or cancel a receiver Payjoin session. A user might cancel a session for any reason, or the wallet might fail it if e.g. it detects a double-spend or cannot proceed past a transient error.

Note that the unit tests for closed sessions will need to be reworked once #1132 is merged, since the expected_receiver_state should be an error.

I used Claude sonnet 4.5 (it's quite good) to write the generic methods and unit tests.

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]

Pull Request Test Coverage Report for Build 18177469540

Details

• 56 of 56 (100.0%) changed or added relevant lines in 2 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.08%) to 84.648%

---

Totals
Change from base Build 18176477486:	0.08%
Covered Lines:	8756
Relevant Lines:	10344

---

💛 - Coveralls

[arminsabouri]

CodeAck

[arminsabouri]

Do you think cancel is simpler than just calling close() on the persister?

[spacebear21]

The difference is that cancel() (and fail()) ensures that a Closed event is added to the log before closing.

[arminsabouri]

Should we push a generic failure error reply? Otherwise the sender will be hanging until expiration.

[spacebear21]

Yes good point, we do need a way to communicate this (and probably cancel() too) back to the sender.

[spacebear21]

I started down an approach where they transition to HasReplyableError to enforce responding to the sender. However there is an outstanding issue in that it needs to differentiate between Cancel and Failure outcomes when replaying the event log, so I think GotReplyableError would need to carry this information somehow.

I'm not sure if we actually need to reply in case of Cancel, assuming the receiver would broadcast the fallback tx?

[DanGould]

Cancel sounds like the unavailable wellKnownError to me, even if broadcast is sufficient

[DanGould]

The only reason I can think of for a receiver to do this would be if the receiver wanted to refuse a naive tx.

A better solution for this example would be having the receiver use req-pj

So for now letting it expire is fine.

[benalleng]

I wanted to pose a question as to why we really need to have these 2 seperate instead of just having application devs use fail() OR cancel() and provide a reason instead of having both of these?