feat: run the payment request fixture and pubky testnet on the versions current Bitkit builds use

[ovitrif]

Refs:

• feat: share paykit state across apps bitkit-android#1401
• feat: share paykit state across apps bitkit-ios#856

Description

• Runs the marketplace fixture's pubky-testnet on the pubky-testnet 0.14.0 crate (built with its own lockfile) so the homeserver grants the LOCK and UNLOCK write locks that current Bitkit builds take before writing Paykit state. The earlier Pubky Core pin answered LOCK with 405, so creating a profile failed in the app.
• Moves the fixture-issuer and rc56-peer services (payment-requests/) to paykit-rs rc62 (f2c5f712) on Pubky 0.14.0, the SDK current Bitkit builds use; the rc56 build published receiver folders the apps no longer read. The service names stay, so lane configs and journeys keep addressing them; payment-requests/prepare is unchanged.
• The issuer publishes its Private Payment List (the regtest endpoint as a private receiving detail) to the peer before each request, which rc62 apps wait for ("waiting for updated private payment details"); /sync of a peer reports the lists it received.
• Keeps the earlier pin as marketplace/pubky-testnet/Dockerfile.core, selectable with PUBKY_TESTNET_IMAGE and PUBKY_TESTNET_DOCKERFILE (the compose file and docs/pubky-marketplace.md show the command).
• Documents that Paykit Server 722ef268 and the headless driver only complete seed against the earlier pin: on 0.14.0 up reaches a ready Paykit Server, and seed stops at companion approval failed: companion authentication failed. Run seed, purchase and verify with the earlier pin until Paykit Server moves.

Out of Scope

• Paykit Server and the marketplace driver: moving them to a revision that works with the 0.14.0 homeserver.

Design

N/A — no UI changes.

Preview

N/A — no user-visible changes.

QA Notes

Journeys

• Bitkit Android E2E build on a 0.14.0 testnet: profile creation reaches Pay Contacts, native LOCK returns 200, UNLOCK 204 and the shared-state PUT 201 (the same requests returned 405 on the earlier pin).

Manual Tests

• ./pubky-marketplace up on the new image: Paykit Server reports ready.
• fixture-issuer and rc56-peer (rc62) start on the new testnet, sign up and publish their Paykit app; /health answers on 3012 and 3013, and payment-requests/prepare runs to the end: one-time proposed, accepted, rejected, canceled and proof-submitted requests and the monthly subscription, with regtest payments.

Automated Checks

• docker compose config resolves with the default image and with PUBKY_TESTNET_IMAGE and PUBKY_TESTNET_DOCKERFILE set to the earlier pin.

[ovi-reviewer]

Suggestion: ♻️ Comment

The test run for synonymdev/bitkit-ios#856 at head 2de4fd5 used this change at commit 9061979. Of the 14 items it needed, 4 did not run: items 1, 5, J9 and J15 stopped with a setup failure before reaching their checks (the reminder check, backup and restore, and the marketplace journey among them). The other 10 items (2, 3, 4, J2, J6, J8, J10, J11, J12 and J17) were not reported as failed or incomplete.

The record gives no sign that the environment change caused the 4 items that did not run, so the run does not show whether the payment request fixture and Pubky testnet work as intended. A new run of those 4 items would settle it.

[ovi-reviewer]

Suggestion: ♻️ Comment

The run for synonymdev/bitkit-android#1401 at d44d5bb used this change at 3b7bea5. Ten items were planned and four ran: items 1, J8 and J10 passed, and item 3 failed because the app left its cleanup markers pending after the public-only fault recovered, which is the app's own defect and not the environment's.

Six items did not run to a result. Item 2 failed when the app crashed after a committed acceptance hit a lock conflict, which points at the app. Items 5, J12, J13 and J17 were cut short before reaching what they check, so they say nothing about the change. Item J15 could not verify linked peers because the marketplace fixture's receiver request returned HTTP 401 and the purchase driver reported no setup authority. That may be related to this change, but the record does not show whether the change caused it, so the run does not prove the change works or fails.

[ovi-reviewer]

Suggestion: ♻️ Comment

The test run for synonymdev/bitkit-ios#856 at head 976538f used this change at commit 3b7bea5. It needed one item, J8, and J8 failed: the server setup rejected the delivered claim.

Nothing recorded for the failure shows whether the cause is this environment change or the app under test, so this run does not show whether the change works. No other item ran on it, so there is no passing result either. A run where J8 reaches the claim step and either passes or fails with a recorded cause would settle it.

[ovi-reviewer]

Suggestion: ♻️ Comment

The run covered synonymdev/bitkit-android#1401 at head 98a1570 with items J12 and J13, on environment commit 3b7bea5. Both items failed, and only J13 ran.

J13 ran and failed for the app's own reason: the unsupported-details sheet opened as soon as Overview was selected, before the test's explicit Open action, so the step that follows was stale. That is not caused by this environment change.

J12 did not run. The encrypted link to the request issuer stayed in the Linking state, so the request could not be delivered and the proposal call returned HTTP 400. The recorded evidence does not show why the link did not complete, so it does not show whether the issuer update in this change is the cause. The run therefore does not show yet whether the change works.

[ovi-reviewer]

Suggestion: ♻️ Comment

The run tested synonymdev/bitkit-ios#856 at 9cb87b8 against this environment change at 3b7bea5. It needed the change for four items (J11, J12, J15, J17) and none passed, so the run does not show whether the change works.

Only J11 ran to the point of checking the app. The issuer published a btc-lightning-lnurl endpoint and the request row showed 21,000 sats, but Pay then closed the sheet because it found no supported endpoint, so the 21,000 review never appeared. That is a failure in the app's handling of the endpoint, not a fault of the environment change.

J12, J15 and J17 did not complete. In J12 the issuer picks its own payment request id and does not accept the one the journey expects, so the expected row and pay control never appeared. In J15 the Paykit Server cannot store an invoice without a payment deadline, so no marketplace invoice reached the app. J17 stopped when the payer environment shut down after the "no longer available" toast, before the remaining checks. The J12 and J15 evidence describes limits of the fixture and server but does not show that this change caused them, and J17 points to the test setup, so none of them is a verdict on the change either way.