test: add marketplace wallet journey

[ovitrif]

Closes #718

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.

Description

• Defines the integration-fixture protocol and runtime contract, with producer provenance from pubky/paykit-server#2 at 867fc883.
• Documents the pre-launch local-E2E Fulcrum route for both clean wallets.
• Records the fresh-request auto-review, dismissal, and header-bell request-sheet sequence on both platforms.
• Documents the iOS in-sheet back adaptation and scopes Locks content delivery outside this wallet-leg journey.

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. It predates the automatic-review, dismissal, and header-bell parity step; a replacement replay remains required.

QA Notes

Manual Tests

• The accepted replay established a watch-only seller and linked buyer, received the canonical 15,000-sat request, paid it once, and confirmed it after one authorized block.
• The replay recorded PaymentRequestsSheet, request-specific Pay, review, broadcast, and confirmed activity evidence.
• Record the fresh-request automatic review, dismissal, and header-bell return to PaymentRequestsSheet on the current head.

Automated Checks

• Current head 3a571fde is based on 215a9f10; git diff --check passes.
• Current head: every journey XML file parses with xmllint; the marketplace flow matches Android's 29-action request sequence at 419503dc.
• Existing sanitized H.264 replay was retained; SHA-256 ec6f0819c9e4e4066e8969f092328615bb286925599b6f92c733eba4b999c122.
• The older fixture-setup comment is covered by 48a85d1f's local-E2E Fulcrum configuration route.
• GitHub Actions: awaiting the current head 3a571fde.

[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.

[jvsena42]

Checked this as a port of Android #1220. It is a faithful one: same file name, same <journey name>, and 27/27 actions identical bar the single step where the platforms genuinely differ. No Android step dropped, and 13 of the 14 asserted accessibility identifiers resolve in Bitkit/.

The 14th, PaymentRequestPay-<id>, does not exist on this branch or on master — but @piotr-iohk already flagged that with the merge-order caveat and approved, so I have not re-filed it. Worth keeping explicit: this journey stops at action 18 of 27 until #721 lands.

Three documentation items below.

[jvsena42]

Checked every selector this journey names against the iOS codebase — all resolve except PaymentRequestPay, which is still absent from master (the CustomButton at PaymentRequestsView.swift:82-90 has no .accessibilityIdentifier; git grep PaymentRequestPay origin/master is empty). That's the known #721 dependency, already covered by piotr-iohk, so I'm not re-filing it — but there's a wrinkle on it inline.

Three doc-only notes below, none blocking.

[jvsena42]

Re-reviewed at 4ed957f. One parity note inline — not blocking. Docs-only, nothing runs these in CI, and Paykit UI is behind the Dev Settings flag.

Your pushed fixes are correct, and I checked them against real code rather than just confirming they landed:

• Paykit UI precondition — the path, id and confirmation step all match: DevSettingsView.swift:5 binds @AppStorage(PaykitFeatureFlags.uiEnabledKey), the toggle at :88-104 carries testIdentifier: "PaykitUiToggle", the warning alert with the Enable button is at :208-215, and Settings → Advanced → Dev Settings is AdvancedSettingsView.swift:35 gated on Env.isDebug.
• Capability enumeration — falsifiable and right. PubkyAuthClaim.watchOnlyAccountCapabilities is /pub/paykit/v0/bitkit/server/:rw,/pub/paykit/v0/private/bitkit/server/:rw; displayPath drops the trailing slash and displayAccess renders rw as READ, WRITE, and permissionRow puts both in the tree as plain Text. Exactly what the action now claims.

Everything else resolves: the auth ids (PubkyAuthWatchOnlyConsent, PubkyAuthWatchOnlyApprove, PubkyAuthAuthorize, PubkyAuthOK), PaymentRequestRow-<id>, PaymentRequestsScreen, and the screen's active card really does expose Pay/Dismiss for an actionable request. Actions 1-15 and 17-27 match Android head one-to-one modulo the id/testTag vocabulary. PaymentRequestPay-<id> still being absent is the known #721 dependency piotr-iohk already has covered, so I'm not re-filing it.

I also chased whether the naming-table row and the "iOS opens the persistent screen instead of Android's transient sheet" sentences were wrong, since iOS does have PaymentRequestsSheet and PaymentRequestsBell verbatim. They're fine as written — the prose says the journey drives the screen, which is an accurate surface choice, and the table row is there because I asked for it. Leaving that alone.