billing: add --dry-run mode and always send manual invoices

[jshearer]

--dry-run

The trial-run workflow used testmode Stripe, which lacks livemode invoice state, so already-invoiced manual bills showed up as phantom creates. --dry-run makes the run read-only so it can be pointed at livemode.

Per-invoice work is split into read-only classify and write-only execute; a dry run stops after classify, so both modes share one decision path. The preview also mirrors the billing-email resolution of a real run and reports tenants that would fail. It cannot validate the final invoice total, which requires creating the invoice.

Manual invoices always use send_invoice

Contracts and one-off charges are sent for the customer to pay rather than auto-charged, regardless of --charge-type: at creation, when refreshing an existing draft, and in the send phase. Nothing ever switches a draft back to charge_automatically.

Hardening

• --recreate-finalized voids open invoices instead of attempting a delete Stripe rejects, and recovers a run that voided but failed to recreate. Replacements are reported as a distinct Replaced result.
• Manual bills that already have an open, paid, void, or uncollectible invoice are skipped as AlreadyProcessed instead of erroring, and are excluded from --recreate-finalized.
• Payment-method state is read from Stripe directly

[strix-security]

Strix Security Review

No security issues found.

Review summary

Reviewed the full billing-integrations diff, with focused attention on the new commit delta (failure reporting and re-verification in crates/billing-integrations/src/send.rs) plus the --dry-run classify/execute split and manual-invoice send_invoice enforcement in publish.rs. All new and touched SQL remains fully parameterized via sqlx bind parameters ($1/$2), with the only change being removal of the now-unreliable has_payment_method lookup and schema-qualifying internal.invoices_ext. The new Stripe interactions (customer search, invoice retrieval/void/delete, collection-method reconciliation, finalization re-checks) operate on operator-supplied CLI arguments and control-plane database values, not attacker-controlled input, and add read-only and re-verification hardening rather than new exposure. No injection, authentication/authorization, secret-handling, SSRF, path traversal, or data-exposure issues were identified in the changed code.

_{Updated for a954e01.}

---

Reviewed by Strix
_{Re-run review · Configure security review settings}