fix(payments)(#391): guard checks sourceTokenIds + load-tail SENT reconciliation

[vrogojin]

Fixes #391.

What

Two independent fixes for the false-positive DUPLICATE_BUNDLE_MEMBERSHIP throw seen in short-lived CLI usage when a previously-sent recipient token round-trips back to the sender.

A. assertNoDuplicateBundleMembership now compares against sourceTokenIds. The pre-fix comparison against entry.tokenIds was a category error — tokenIds is the RECIPIENT mint-output set; the invariant the guard defends ("don't burn the same source twice") is expressible only against the SOURCE set. SENT branch removed: UxfSentLedgerEntry has no source field, the prior comparison was the same category error.

B. load() fires a one-shot SENT-reconciliation tail sweep. The periodic worker waits 60s before its first scan; short-lived CLI processes exit before any cycle fires, leaving delivered-instant OUTBOX entries live indefinitely. The tail sweep closes that gap by tombstoning prior entries whose SENT companion already exists. Mirrors the orphan-spending sweep auto-invocation at PaymentsModule.ts:3782-3810.

Why both

Either fix alone breaks the user-visible failure mode:

• A alone — guard becomes accurate; even if entries persist, round-trips are accepted.
• B alone — entries are tombstoned promptly; even with the category-error guard, there's nothing live for it to false-positive on.

Both together: correct invariant + clean operational state.

Files

• modules/payments/PaymentsModule.ts — guard rework (assertNoDuplicateBundleMembership) and load-tail sweep (after the detectOrphanSpendingTokens() block at load() tail).
• tests/unit/modules/payments/duplicate-bundle-guard.test.ts — reworked end-to-end (12 tests). Pins source-side rejection + duplicate-bundle guard false-positives on token round-trips + OUTBOX entry persists indefinitely in short-lived CLI #391 round-trip-false-positive avoidance + pre-H5 back-compat + SENT-no-longer-participates.
• tests/unit/modules/payments/load-sent-reconciliation.test.ts — new (3 tests). Pins the load-tail tombstone of a pre-existing delivered-instant entry with matching SENT row.

Test plan

• npx vitest run tests/unit/modules/payments/duplicate-bundle-guard.test.ts — 12/12 pass
• npx vitest run tests/unit/modules/payments/load-sent-reconciliation.test.ts — 3/3 pass
• npx vitest run tests/unit/modules/ tests/unit/payments/ — 3362/3362 pass
• npx tsc --noEmit clean
• npm run build clean
• npx eslint modules/payments/PaymentsModule.ts <new test files> — 0 errors (5 pre-existing warnings untouched)
• Soak repro: re-run user's 4-send CLI flow against testnet end-to-end (post-merge, with deployed CLI build).

Risk

• Existing dispatcher integration tests cover the legitimate-rejection path (makeOutboxEntry({ sourceTokenIds: ['tok-A'] }) → guard fires on ['tok-A'] candidate). No behavior change there.
• Pre-H5 entries have always been forward-compat (worker treated them as "no recovery target"); skipping them in the guard is consistent with that.
• The load-tail sweep is fire-and-forget with the same error-swallow semantics as the orphan sweep. A failure cannot break load().

[vrogojin]

Erratum — commit references to "#393"

Commits 0fe9582 (fix(payments)(#393): disable automated CID-based delivery via kill-switch) and 39c1b54 (test(payments)(#391/#393): handle INLINE_CAR_TOO_LARGE soft-pass in soak + e2e) reference "#393" — that issue number was already in use for an unrelated state-transition v2 migration (#393). The canonical tracking issue for the automated-CID disable is #394. No code change needed; this comment is the breadcrumb so future searches land on the right place.