Onboarding/billing robustness follow-ups (from release #50 Gemini review)

[mahmutkaya]

Two robustness suggestions Gemini raised on the release PR #50. They concern already-released code (shipped in 4167a72 via #45), surfaced on the release PR only because the squash-based develop→main PR re-lists #45's commits. Deferred out of #50 (a release of the unrelated onboard picker #49 + CI #48) to avoid changing live billing/onboarding behavior in an unrelated release. Both are worth doing in a dedicated PR:

1. lib/actions/onboarding-actions.ts — resolveTenantClient should promote an existing client's status to LIVE on onboard

Currently, if a Client already exists for the slug (same partner), it's returned as-is. If it was LEAD/CONTACTED/AGREED, onboarding it (creating a billing plan) leaves its CRM status stale. Consider flipping to LIVE when onboarded. Product nuance to decide: what about a CHURNED client being re-onboarded?

2. lib/billing-onboarding.ts — startFirstPayment reuses an open checkout URL without an age check

Mollie hosted-checkout URLs expire (~1h). Reusing an open/pending first-payment checkoutUrl older than the expiry lands the partner on a Mollie error page. Add a freshness threshold (e.g. only reuse if Date.now() - createdAt < 60min), else mint a fresh checkout.

Not money-safety issues (no double-charge risk); UX/consistency robustness.

[mahmutkaya]

Additional findings from Gemini's re-review of the release PR #50 (same class — already-released #45 code, not in the #48/#49 delta):

3. lib/actions/onboarding-actions.ts onboardPartnerAction — partial-failure on email send (Gemini HIGH): user/client/billing are committed before emailOnboardInvite; if sendEmail throws (network-level fetch rejection) the action 500s with records already created, and the re-onboard guard then blocks a retry. Consider ordering the invite-link return / making the side effects resilient (the link is also surfaced in the UI, so email failure needn't 500). Pre-existing since feat(billing): partner onboarding + self-serve monthly subscription #45.
4. lib/actions/onboarding-actions.ts resolvePartnerUser — case-insensitive email lookup: findUnique({where:{email}}) is case-sensitive; a differently-cased existing email could slip the reuse path and hit the unique constraint. Consider normalizing/【findFirst mode:insensitive】.
5. lib/billing.ts:182 — non-null assertion on payment.customerId: prefer ?? fallback over !.

Items 3–5 are pre-existing #45 behavior; grouping with 1–2 for a dedicated onboarding/billing-robustness PR.