feat: payment-requests fixture services for wallet journeys

[ovitrif]

Stacked on #12
Refs: synonymdev/bitkit-android#1365

Description

• Fills the skipped J1 review-lane gap with an opt-in fixture-issuer that publishes a regtest Paykit endpoint and sends one-time, deadline-bearing Payment Requests to a linked peer.
• Adds an opt-in rc56-peer that accepts, rejects, cancels and pays those requests through the rc56 SDK, then sends a proof backed by a regtest transaction.
• Adds payment-requests/prepare to create and verify the J1 one-time states and a monthly subscription with one confirmed paid period and a current unpaid period. It prints the request ids and txids for inspection.
• Reuses the Pubky testnet, regtest chain and Paykit Server setup from the marketplace fixture. The rc56 clients use the SDK pinned to 24162ebb; their containers and upstream images are pinned. The branch contains the open marketplace fixture commit because the requested PR base is main.
• Documents startup, wallet linkage, request issuance and reset in the README.

Out of Scope

• Bitkit app state preparation and on-device J1 execution: these require a disposable app build on the local testnet and a controlled client or state import path for the app identity's accepted and paid history.
• Persistence across a Pubky testnet restart: both fixture identities and SDK records are disposable.

Design

N/A — no UI changes.

Preview

N/A — no user-visible changes.

QA Notes

Journeys

N/A — the existing Android deadline-history journey was not run on a device.

Manual Tests

• ./pubky-marketplace up and ./pubky-marketplace seed → local Paykit Server became ready and the disposable testnet seller completed setup.
• fixture-issuer and rc56-peer on the local stack → both /health endpoints answered; the peers linked, exchanged a one-time deadline-bearing request, accepted it, sent a regtest transaction and delivered its proof.
• Bitkit Android J1 on device → not run; this repository has no app build or app identity state hook.

Automated Checks

• ran docker compose config with and without both profiles; plain Compose excludes the new services.
• ran cargo check --locked, cargo fmt --check, bash -n, shellcheck and git diff --check.
• built the pinned fixture image with Docker, then ran ./payment-requests/prepare against live services. It verified proposed, accepted, rejected, canceled and proof-submitted one-time records; accepted and proposed monthly records; one monthly proof; and at least one confirmation for both regtest payments.
• exercised /proof with an existing regtest wallet txid; it returned ProofSubmitted and proof_sent: true.

Lane setup

• Start the marketplace fixture, seed it, then build and start the two payment-requests services using the README commands.
• Point a disposable Bitkit build at the local Pubky testnet and link its Paykit identity to fixture-issuer using the /info, /link and /sync endpoints.
• Issue a request to the app identity with /request; for accepted and paid app history, arrange the controlled client's rc56 records for that same app identity. The headless prepare command verifies the backend states but does not inject records into a separate wallet.
• Run Android J1 on device and record its row ids and history result. The app-side fixture path is not demonstrated yet.

[ovi-reviewer]

Verdict: ♻️ Comment

Review: diff 21 files.

Findings:
3 inline (2 MEDIUM, 1 LOW)

---

Reviewed by claude-opus-5-5-high via gh-pr-review-loop skill
Commands: @ovi-reviewer review · test · retest (author)

[ovi-reviewer]

Tested: this fixture at 50e0a29 (stacked on the marketplace fixture at 610fa5e) drove journey J1 of synonymdev/bitkit-android#1365 (journeys/payment-requests/payment-deadline-history.xml) on an Android 15 emulator. #1365 is merged, so the app is bitkit-android master at 90a91f4 (the merge of #1365), a debug build pointed at the local Pubky testnet.

Result: 13 of 23 journey actions passed, 10 could not run, none failed. Only the fixture issuer was called; the rc56-peer and prepare were not needed.

Passed:

• The app saves the issuer as a contact and links to it (issuer /link with initiate, see the findings).
• One-time requests with a deadline sync into the Payments tab (1, 2, 8), and the proposed row's details show no Pay action (7).
• After the issuer's /cancel, the request stays in Payments (5). The app shows no lifecycle label, so the issuer's records are the proof of the Canceled state.
• A monthly proposal with a period-start deadline (16-20) arrives in about 20 seconds. Review & Subscribe says the payment details are not supported yet and has no Subscribe swipe control.
• After a restart, the one-time rows and the proposal remain (23).
• No pending-request bell or sheet appeared while the deadline requests were present.

Not run (actions 3, 4, 6, 9, 10, 12, 13, 15, 21, 22): accepted, rejected and completed one-time rows, and an active monthly subscription with a paid period. Each state needs the payer to accept, reject or pay. The payer is the app, which has no control for a request with an actual-payment deadline. The issuer is the payee, so its /accept and /reject answer "local identity is not the payer". prepare builds these states between the two headless peers only, and that history does not belong to the app identity, as the README says. A route needs an app build that imports fixture state, or another controlled payer.

Findings:

• The README says to POST /link with mode: "accept" on the issuer for the app. The SDK picks the role from the two Pubky keys, and the smaller key initiates. Here the app's key sorts after the issuer's, so the issuer must send initiate. With accept both sides stayed responders and /sync never reached linked. A later initiate returned the stored record unchanged, and only a restart of the issuer clears it. Document the rule in the README, or have /link choose the role.
• /request always sets a deadline, so the fixture cannot issue a request without one.
• Fixture commands print the Docker Compose buildx warning on stderr.

Current head: 067988d, rebased onto the marketplace fixture at c902407. It has the same three commit subjects as the tested stack. The rebase and the changes in c902407 have not run on a device.

Approve for what the run exercised: issuer and link, one-time and monthly request delivery, cancel and restart persistence.