test: add marketplace wallet journey

[ovitrif]

Closes #718

Description

Adds the two-wallet Pubky marketplace wallet-leg journey for watch-only seller setup, linked-buyer Payment Request receipt, on-chain approval, broadcast, and regtest confirmation.

The journey now defines the integration-fixture protocol and runtime contract, with producer provenance from pubky/paykit-server#2 at revision 867fc883.

The final exact-head iOS buyer replay selected request 5f07c465-dc67-42ce-96a0-4209e5389618 through its request-specific Pay action. One authorized swipe broadcast 2822f6b43aebeb228e0bfe96c1b201cf41e0ed46a677d704403dc629b09d6f2a with a 15,000-sat request output and 143-sat fee. One authorized block, 6235eff06b00ed2b736635913e76269cd6524c4fed80f247d244102806816aed, confirmed it at height 16403; signed Paykit reached confirmed/1/true, the Locks bundle completed without failure, and the mempool emptied.

Linked Issues/Tasks

• Parent epic: epic: Pubky marketplace wallet support #712
• iOS journey: test: add the Pubky marketplace wallet-leg journey #718
• Android counterpart: test: prove the android pubky marketplace wallet leg bitkit-android#1212
• Paykit Server producer contract: fix: emit canonical Paykit requests and retry initial links pubky/paykit-server#2

Preview

52-ios-marketplace-wallet-leg.mp4

The sanitized replay shows the request-specific Pay action, 15,000-sat seller review, one swipe to SendSuccess, paid request history, confirmed activity, and exact transaction details.

QA Notes

Manual Tests

• The controlled seller setup retained watch-only account index 1 without Bitcoin spending authority.
• A fresh exact-head buyer enabled contact payments, saved the seller, linked at bitkit/wallet, and received the canonical 15,000-sat request.
• PaymentRequestPay-5f07c465-dc67-42ce-96a0-4209e5389618 opened a 15,000-sat review for hbn4...pfiy with a 143-sat fee and enabled GRAB.
• One swipe reached SendSuccess; the zero-confirmation checkpoint showed the exact amount-matched output, signed Paykit detected/0/true, Locks pending, and one mempool transaction.
• One block produced signed Paykit confirmed/1/true, completed Locks state, an empty mempool, and Bitkit sync at matching height 16403 and tip.
• Confirmed iOS activity showed StatusConfirmed, the 15,000-sat payment, 143-sat fee, seller, and exact transaction; the accepted request remained without Pay or Dismiss actions.

Automated Checks

• Every journey XML file parses with xmllint.
• git diff --check passes.
• The integration merge's production tree is identical to merged Pay-selector head 70cd26346c6a539f792564e2e9bddb41cc00eecc.
• The sanitized H.264 replay was sampled across every segment and cut boundary; SHA-256 ec6f0819c9e4e4066e8969f092328615bb286925599b6f92c733eba4b999c122.

[greptile-apps]

Greptile Summary

This PR adds an agent-evaluated, two-wallet Pubky marketplace journey and documents its external fixture, evidence contract, and accepted regtest replay.

• Registers the new marketplace journey in the journey index.
• Defines seller watch-only setup, buyer request payment, broadcast, and confirmation steps.
• Records fixture requirements, accessibility identifiers, and exact-head acceptance evidence.

Confidence Score: 4/5

The PR appears safe to merge after clarifying how operators can configure Electrum on clean simulators before initial wallet startup.

The journey and selector conventions are otherwise consistent with the agent-evaluated corpus, but the custom Electrum precondition cannot be followed through the documented in-app configuration path as currently written.

Files Needing Attention: journeys/pubky-marketplace/wallet-leg.xml and journeys/pubky-marketplace/README.md

Important Files Changed

Filename	Overview
journeys/README.md	Registers the new one-journey marketplace suite and its external-fixture requirement.
journeys/pubky-marketplace/README.md	Documents the fixture contract and accepted replay, but repeats an incomplete pre-first-launch Electrum setup instruction.
journeys/pubky-marketplace/wallet-leg.xml	Defines the complete two-wallet payment walkthrough, with an initial Electrum configuration precondition that lacks an executable setup route.

Sequence Diagram

sequenceDiagram
    participant S as Seller wallet
    participant F as Integration fixture
    participant B as Buyer wallet
    participant R as Regtest chain
    S->>F: Authorize watch-only account claim
    B->>F: Link seller and enable contact payments
    F-->>B: Deliver Payment Request
    B->>B: Review and approve payment
    B->>R: Broadcast transaction
    F->>R: Mine one authorized block
    R-->>B: Confirm transaction
    F-->>B: Report completed marketplace purchase

Loading

_{Reviews (1): Last reviewed commit: "test: record exact marketplace journey r..." | Re-trigger Greptile}

[greptile-apps]

Electrum precondition lacks setup route

The journey requires configuring the fixture endpoint before either wallet's first launch, but the supported configuration flow runs inside the launched app and persists the endpoint only after restarting and validating the node. Document a concrete pre-launch configuration procedure; otherwise operators cannot reliably establish the clean-wallet starting state and can begin the journey on the default regtest chain.

Knowledge Base Used: Restore Electrum connection rollback

[ovitrif]

Addressed in 48a85d1: the journey now requires the fixture Fulcrum endpoint at tcp://127.0.0.1:60001 before either first launch and provides the exact xcodebuildmcp local-E2E build command for both simulators. This uses Bitkit’s local-E2E default, so no stored in-app Electrum override is required.

[piotr-iohk]

QA LGTM on the journey docs. Did not re-run the isolated marketplace fixture.

Checked latest (48a85d1f):

• Suite is registered; xmllint --noout journeys/pubky-marketplace/wallet-leg.xml passes.
• Greptile Electrum note is addressed: E2E_BUILD + E2E_BACKEND=local resolves Electrum to tcp://127.0.0.1:60001 in Env.electrumServerUrl. No in-app override required.
• IDs that already exist on this tree: PubkyAuthWatchOnlyConsent / Approve / Authorize / OK, ContactPaymentsToggle, PaymentRequestsScreen, PaymentRequestRow-<id>, ReviewAmount, ReviewContactRecipient, GRAB, SendSuccess, ActivityAmount, ActivityTxDetails, StatusConfirmed.

Note, not a blocker if merge order is explicit:

• PaymentRequestPay-<id> is not on this branch. It is added in #721 (PaymentRequestsView.swift). The README already lists #714 / sibling app work as a dependency. Do not treat this PR’s tree as an executable journey until that Pay selector is on master (or merge #721 first).

I am not blocking on not replaying the two-simulator Locks fixture. The contract and the 2026-09-02 acceptance record are consistent with the Android counterpart.