Recover failed Stripe payments with Linq iMessage texts

Build me a code workflow that recovers failed Stripe payments by texting the customer instead of relying on Stripe's dunning email. Every step is a fixed lookup or send, so this should be deterministic code, not an agent.

Trigger: a webhook from Stripe for the invoice.payment_failed event.

Steps:

1. Stripe Retrieve Invoice using the invoice id from the webhook payload. Pull the customer id, the hosted_invoice_url, and a short description from the first line item (fall back to "your subscription" if there is no line item description).

2. Stripe Retrieve Customer using that customer id. Pull the name and the phone field. If the phone field is empty, log "skipped: no phone on file" and stop. Do not raise an error.

3. Linq List Phone Numbers and pick the first active sender number on the account. If the workflow has more than one, the user should be able to configure which one to use.

4. Linq Check iMessage Capability for the customer's phone from the chosen sender. If Linq cannot reach the number (unsupported region or no capability for any service), log "skipped: unreachable" and stop. The capability check just tells us whether to try at all; the actual chat will route to iMessage, RCS, or SMS automatically.

5. Linq Create Chat from the chosen sender to the customer's phone (E.164) with an initial text part: "Hi {first name}, your payment for {description} didn't go through. You can update your card and retry here: {hosted_invoice_url}. Reply STOP to opt out." If the Stripe customer has no name, use "there" as the greeting. Keep the message under 320 characters.

Notes:

- The customer's phone on Stripe must be E.164 (for example +14155550123). If it isn't in that format, try a simple normalization; if normalization fails, treat it like a missing phone and skip.

- Linq enforces a limit of 30 messages per sender/recipient pair per 60 seconds. This workflow only sends one message per failed payment per customer, so we should not hit it under normal usage. Just surface the Linq error if it ever does fire.

- Output of the workflow run: a small JSON object with { invoice_id, customer_id, action: "sent" | "skipped:no_phone" | "skipped:unreachable", chat_id (if sent), reason (if skipped) }. This makes it easy to glance at the runs and see what happened.