feat: port payjoin core to no_std

[caarloshenriq]

Summary

This is a implementation of no_std support for the payjoin crate,
enabling its use on embedded devices

As discussed in #942, running payjoin logic on a hardware signer enables
stronger security guarantees: the device can verify the fallback transaction,
compare it against the payjoin proposal, and only sign previously-approved
inputs — without trusting the host machine.

Feature Architecture

A new v2-std feature was introduced to separate the state machine logic
from networking dependencies:

Feature	Description
alloc	bare metal support, state machine logic only
v2	async payjoin session logic without networking
v2-std	v2 + networking (url, ohttp, hpke, bhttp, http)
std	full std support with tokio, serde_json, bitcoin/base64

Verified Build Targets

• cargo build -p payjoin --no-default-features --features v2,alloc
• cargo build -p payjoin --no-default-features --features v2,alloc --target thumbv7em-none-eabihf-p payjoin
• cargo build -p payjoin --no-default-features --features v2,std

Notes for Reviewers

Please review commit by commit:

refactor: introduce no_std/alloc feature split in payjoin core
The main structural change — replaces std:: with core::/alloc:: and gates std-only deps behind #[cfg(feature = "std")] or #[cfg(feature = "v2-std")].

fix: gate v2 std-only code behind cfg features
Extends gating to v2 send/receive and persist. Key decisions: HasReplyableError now carries fallback_tx in both configs to preserve fallback through replay; MaybeSuccessTransition::deconstruct uses Save instead of SaveAndClose on success.

fix: update payjoin-ffi for no_std feature split
Minimal FFI updates to match new AsyncSessionPersister bounds.

fix: restore OHTTP test constants and enable v2 feature in test utils
KEM, KEY_ID, SYMMETRIC were dropped upstream without updating internal tests. Restores them in payjoin-test-utils/src/v2.rs.

chore: update CI, lock files and flake for no_std targets
Adds thumbv7em-none-eabihf to CI and ARM cross-toolchain to the Nix dev shell.

AI Assistance

This implementation was developed with AI assistance (Claude, Anthropic).

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](https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md#committing-patches).

[coveralls]

Coverage Report for CI Build 27779438342

Coverage decreased (-0.6%) to 84.654%

Details

• Coverage decreased (-0.6%) from the base build.
• Patch coverage: 104 uncovered changes across 14 files (292 of 396 lines covered, 73.74%).
• 56 coverage regressions across 6 files.

Uncovered Changes

Top 10 Files by Coverage Impact	Changed	Covered	%
payjoin/src/core/send/v2/mod.rs	51	27	52.94%
payjoin/src/core/persist.rs	89	75	84.27%
payjoin/src/core/uri/v2.rs	50	36	72.0%
payjoin/src/core/send/v2/error.rs	11	0	0.0%
payjoin/src/core/receive/v2/mod.rs	19	10	52.63%
payjoin/src/core/send/error.rs	22	14	63.64%
payjoin/src/core/ohttp.rs	7	1	14.29%
payjoin/src/core/uri/mod.rs	105	100	95.24%
payjoin/src/core/error.rs	6	2	33.33%
payjoin/src/core/time.rs	5	1	20.0%
Total (22 files)	396	292	73.74%

Coverage Regressions

56 previously-covered lines in 6 files lost coverage.

File	Lines Losing Coverage	Coverage
payjoin/src/core/persist.rs	31	92.32%
payjoin/src/core/receive/v2/mod.rs	16	88.68%
payjoin/src/core/receive/v2/error.rs	4	38.18%
payjoin/src/core/send/v2/error.rs	2	30.23%
payjoin/src/core/uri/error.rs	2	4.55%
payjoin/src/core/send/error.rs	1	42.79%

---

Coverage Stats

Relevant Lines:	14753
Covered Lines:	12489
Line Coverage:	84.65%
Coverage Strength:	370.52 hits per line

---

💛 - Coveralls

[DanGould]

Great to see this take off here. My biggest question is about v2-std which expresses that it's about "networking" but really it's the wire serialization. Is it possible to use the library without that? I'm not sure it is.

[benalleng]

Looks like a good start, though there are some feature organizations I have some questions about.

[caarloshenriq]

My biggest question is about v2-std which expresses that it's about "networking" but really it's the wire serialization. Is it possible to use the library without that? I'm not sure it is.

After reviewing the code, v2-std as a standalone feature had no clear use case, any consumer that needs OHTTP networking will reach for v2-ohttp or io, and v2-std alone didn't even compile correctly due to untested feature combinations. I've collapsed v2-std into v2-ohttp, simplifying the feature hierarchy to: alloc → v2 → v2-ohttp → io.