Decouple directory poll timing

[bc1cindy]

removes the cadence + R_i poll-timing leak in BIP77 v2

the directory read each party's relay round-trip latency (R_i) from the regular poll interval, distinguishing sender from receiver. The client now polls on an independent Poisson schedule (the Loopix client-emission model), so the interval no longer carries R_i

the client can only own its cadence once the directory stops holding the GET, so payjoin-mailroom (non-blocking GET) is the precondition for payjoin-cli (Poisson polling). (split into separate PRs would busy-loop against a still-blocking directory)

note: drops BIP 77's recommended 30s-blocking GET (should; 202/200 response codes unchanged).

part of #440

Disclosure: co-authored by Claude

[coveralls]

Coverage Report for CI Build 27853602031

Coverage decreased (-0.04%) to 85.171%

Details

• Coverage decreased (-0.04%) from the base build.
• Patch coverage: 14 uncovered changes across 4 files (161 of 175 lines covered, 92.0%).
• 21 coverage regressions across 1 file.

Uncovered Changes

File	Changed	Covered	%
payjoin-cli/src/app/v2/mod.rs	57	49	85.96%
payjoin-mailroom/src/directory.rs	23	19	82.61%
payjoin-mailroom/src/db/mod.rs	22	21	95.45%
payjoin/src/core/schedule.rs	37	36	97.3%
Total (5 files)	175	161	92.0%

Coverage Regressions

21 previously-covered lines in 1 file lost coverage.

File	Lines Losing Coverage	Coverage
payjoin-mailroom/src/db/mod.rs	21	71.95%

---

Coverage Stats

Relevant Lines:	14890
Covered Lines:	12682
Line Coverage:	85.17%
Coverage Strength:	382.55 hits per line

---

💛 - Coveralls

[benalleng]

CACK c9a0ceb
Tested against master test poll timing.
master ran 5 send_receive_payjoin_v2_* payjoin-cli e2e tests with the following data
I tried to do a little more precise per-poll timing but I found that to be too much signal for the purpose of my smoke testing.

branch	Run 1	Run 2	Run 3	Run 4	Run 5	Avg	SD
master	9.17	9.16	9.11	9.18	9.28	9.18	0.06
poll-timing	18.47	20.79	24.66	14.69	19.65	19.21	3.36

I do have a few questions about seemingly important details that may be lost in their obscurity

[bc1cindy]

• moved the poll schedule into the payjoin crate, payjoin::schedule::PollSchedule (sans-IO, next_gap() -> Duration). new() bakes POLL_MEAN so clients can't pick a divergent rate, payjoin-cli consumes it.
• elaborated the "Return mailbox GET" commit message to explain the deferred v2-waitmap removal.
• pinned the SplitMix64 generator with a next_uniform test vector (cargo-mutants flagged the bit-ops as untested)

this now adds a small payjoin-core API, beyond original "core unchanged" scope discussed with @DanGould in #440

follow-ups (out of scope here):

1. BIP 77 draft wording for the timing change
2. expose PollSchedule over payjoin-ffi
3. per-integration adoption of the shared cadence (cli done; ldk-node, Liana, Cake, BBM, Boltz)
4. remove the now-unused v2 waitmap (wait_for_v2_payload / wait_v2 / pending_v2).
5. re-clock POST emission, directory mixing delay, cover traffic.

makes sense to follow this approach?