test(payments/transfer): close V6-RECOVER test-coverage gap + nightly soak CI (Audit #333 follow-up)

[vrogojin]

Stacked PR. Built atop #355 (H7) → #354 (H5) → #353 (H4) → #352 (H3) → #351 (H2) → #349 (H1) → #348 (C3) → #347 (C2) → #346 (C1).

Why this PR

While running a verbose-debug soak on integration/all-fixes-vintage code I observed 100+ [ERROR] [V6-RECOVER] Stranded receive ... permanent recipient-address mismatch lines in the §C → §D handoff. Investigating: the soak still passed (exit 0), but the question came up — why doesn't any unit/e2e test catch this regression mode?

Reviewing the test coverage:

Test	What it covers
PaymentsModule.recipient-address-mismatch-recovery.test.ts (12 tests)	Helpers in isolation, SDK fully mocked at the import boundary
PaymentsModule.proof-polling-persistence.test.ts #269 (1 test)	Mocks finalizeTransferToken to throw; asserts the throw is classified as permanent
Nothing	Composition of tryRecoverSigningServiceForRecipient + real SDK predicate construction
Nothing	Cross-process / multi-daemon / testnet integration

So the regression mode "tryRecover returns a candidate but the SDK's verifyRecipient later rejects it" was structurally invisible to CI. The soak surfaces it, but only on a developer's laptop.

What this PR adds

L1 — Real-SDK integration test

tests/integration/payments/v6-recover-real-sdk-recovery.test.ts (4 tests):

• Happy path — sender targeted a sibling HD index in the recipient's inventory; tryRecover finds it AND the recovered signer's UnmaskedPredicate.create(...).getReference().toAddress() (REAL SDK call, no mock) derives the exact same address the sender computed.
• Negative path — sender targeted an HD index NOT in inventory; tryRecover returns null (no false-positive candidate that the SDK would later reject).
• Iteration tolerance — deriveAddressInfo() throws for one index; the loop continues and finds the match further down.
• Composition — full finalizeTransferToken integration at the address layer: primary derived ≠ expected → tryRecover → real UnmaskedPredicate.create from recovered signer → the resulting recipient address byte-equals the transferTx target. Proves the SDK's downstream verifyRecipient cannot throw "Recipient address mismatch" against this state.

L3 — Nightly CI workflow

.github/workflows/soak-nightly.yml:

• Triggers: schedule (06:00 UTC nightly, off-peak for testnet) + workflow_dispatch (on-demand triage).
• Skip-not-fail probe: if testnet aggregator or Nostr relay is unreachable, the job exits with a workflow-summary "skipped — external infra down" rather than failing (third-party outages cannot block releases).
• Setup: checks out sphere-cli alongside sphere-sdk, links the local build, makes the sphere binary discoverable on PATH.
• Run: invokes manual-test-full-recovery.sh with SPHERE_DEBUG=*, captured to soak.log.
• Metrics surfaced in workflow summary: V6-RECOVER count, Stranded receive count, POINTER_MONOTONICITY_VIOLATION count, bcast_pub > 0 count, script exit code.
• Artifacts: full log + workspace, 30-day retention on failure, 7-day on success.

L2 — resolveUnconfirmed end-to-end

Rather than write a separate heavyweight test that constructs a full SDK Token instance, I folded the L2 value into the L1 file as the composition test above. The composition test exercises steps 3-5 of finalizeTransferToken with real SDK objects, which is structurally equivalent to driving resolveUnconfirmed → resolveLegacyReceivedTokenViaGetProof → onProofReceived → finalizeStrandedReceivedToken at the address-derivation layer — the layer where the V6-RECOVER error originates.

The full stClient.finalizeTransaction round-trip (state + proof verification) requires constructing real SDK Token + TransferTransaction instances with real authenticated proofs — that's L3's job (the soak does the full thing for real).

Soak confirmation

While developing this PR I ran one full soak with SPHERE_DEBUG=*:

• Result: EXIT=0 (pass), 16 section banners reached, all §A/§B/§C/§D/§E assertions cleared.
• V6-RECOVER count: 103 (operator-visible signals, classified as permanent per drainPendingFinalizations retries permanent verification failures indefinitely (V6-RECOVER drain loop) #269, no impact on soak outcome).
• Reframe: the V6-RECOVER errors are known-tolerated — they signal recovery-worker activity, not failure. The L1 composition test proves that when the inventory has the matching HD index, the SDK cannot throw the mismatch — closing the false-positive risk that's structurally invisible to existing tests.

Test plan

• 4 new L1 integration tests (real SDK, no mocks for SigningService / UnmaskedPredicate / TokenId / TokenType / HashAlgorithm)
• L3 workflow YAML parses cleanly (js-yaml + python3 yaml.safe_load)
• All 451 unit test files (8185 tests) pass
• tsc --noEmit clean
• eslint clean on the new file
• One full soak (manual-test-full-recovery.sh) exits 0 against the current branch state

Audit traceability

• Issue: Audit: integration/all-fixes — money-path subsystems (UXF / Profile / transfer pipeline) #333 follow-up (V6-RECOVER test-coverage gap surfaced during soak verification)
• Related: existing manual-test §C.4 — downstream Recipient address mismatch + pointer-storm flakiness (post-#251 follow-up) #255 helper coverage + existing drainPendingFinalizations retries permanent verification failures indefinitely (V6-RECOVER drain loop) #269 classifier coverage