Partial-payment client mail body "No action is needed right now" reads as completion

[n8bar]

What

App\Mail\InvoicePaymentAcknowledgmentClientMail fires when a new on-chain payment is detected against an invoice — including partial payments. Body opens with:

A Bitcoin payment of X BTC was detected.
No action is needed right now.
The invoice issuer has been notified to review it promptly.

In a partial-payment scenario, the line No action is needed right now reads as reassurance that the recipient is done. A client who knew they sent partial reads it correctly; a client who accidentally underpaid (or didn't realize) reads it as confirmation they've paid in full. The system's intent is "no action while confirmations settle, downstream underpay alert will fire if applicable" — but that's not what the phrasing communicates.

Where

• resources/views/mail/invoice-payment-acknowledgment-client.blade.php (line ~8)

Fix direction

Tighten the copy so it signals "confirmations are still settling — we'll follow up if anything's off" rather than "all done." Candidate phrasings:

• Confirmations are still settling — no action is needed from you while that completes.
• We'll follow up if anything needs attention from you.

Final wording up to maintainer/Nate. Bar: a skimming client should not walk away thinking the invoice is fully paid based on this mail alone, when in fact a downstream underpay alert may follow.

Why the gap exists

By design, the detection-time ack is intentionally low-info because the system doesn't 100% trust state until confirmations settle, and a separate underpay alert handles the "you owe more" call after thresholds confirm. The separation is defensible; the phrasing just needs to match it.

Test plan

• Re-fire mail against the §5.4 partial-payment fixture (50% paid, status partial); eyeball QA confirms the new copy doesn't read as completion
• No spec change required (docs/specs/NOTIFICATIONS.md describes the mail as "low-info ack" — matches new direction)
• Existing tests in tests/Feature/InvoiceDeliveryTest.php and WatchPaymentsCommandTest.php still pass

Tracked in

docs/strategies/19.1_NOTIFICATION_COVERAGE_AUDIT.md §5.4 (post-restructure: findings + fix + re-verify nested under §5.4).

[n8bar]

Implementation extended in §5.4 round 2: in addition to the original wording fix, the partial-scenario body now surfaces outstanding_usd directly to the client when > 0.

Final blade behavior:

• Partial (outstanding_usd > 0): Your invoice currently shows an outstanding balance of $Y. Confirmations are still settling — we'll follow up if anything else needs your attention.
• Full / paid-in-full (outstanding_usd == 0): We're still waiting for the network to confirm — we'll follow up if anything needs your attention.

Mirrors the existing outstanding-balance asymmetry between issuer + client acks: InvoicePaymentAcknowledgmentIssuerMail already conditions on the same outstanding_usd field. Tests in MailBrandingTest, InvoiceDeliveryTest, WatchPaymentsCommandTest still pass (49/49).

[n8bar]

Round 3 (refinement): round-2 fix passed eyeball QA on the original criterion ("no longer reads as completion") but surfaced an adjacent ambiguity — body didn't actively read as partial either. Outstanding balance + "confirmations still settling" left it unclear whether the dollar figure was pre- or post-confirmation.

Round-3 partial-branch wording:

This appears to be a partial payment — once confirmations settle, **$Y** will still be due on this invoice. We'll follow up if anything else needs your attention.

Changes from round 2:

• Names the scenario explicitly (This appears to be a partial payment) rather than leaving it for the client to infer from the outstanding balance
• Reframes the dollar figure as a post-confirmation value (once confirmations settle, $Y will still be due) — closes the ambiguity of whether confirmations could move the figure

Spec verification (per docs/specs/PARTIAL_PAYMENTS.md:73-74): outstanding_usd is stable across the confirmation interval — each payment locks its own usd_rate and fiat_amount at detection time, not at invoice creation or view time. So "$Y will still be due" is accurate; confirmations don't move the figure.

appears to be keeps the system honest about not fully trusting state until confirmations land. Full-payment branch (outstanding_usd == 0) unchanged. Tests in MailBrandingTest, InvoiceDeliveryTest, WatchPaymentsCommandTest still pass (49/49).