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 77547ed8 is based on 60e75e18; local verification 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 fixture-setup review is covered by the documented local-E2E Fulcrum configuration route.
• GitHub Actions: unit tests, validation, and E2E status passed; integration tests failed because Blocktank returned Service unavailable in testChannelPurchaseFlow.

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

[jvsena42]

Re-reviewed the delta at 3a571fde. No HIGH/MEDIUM. The parity drift is closed — details on the resolved thread.

Worth noting you fixed it in the direction that preserves coverage rather than the one that just silences the note: the journey now exercises the automatic review and the bell-to-sheet path that Android exercises, instead of keeping the screen-only route and documenting a divergence. Dropping the journeys/README.md naming-table row is right too — that table is the corpus-wide authority on identifiers that genuinely cannot match, and PaymentRequestsSheet/PaymentRequestsBell both exist verbatim on iOS, so the row would have misled the next port.

The remaining stated difference — iOS uses the review's in-sheet back control where Android uses system back — is a real platform difference and reads correctly.