v0.14.2

New Features

• Autumn payment method setup and billing portal — the Autumn emulator now models the card on file end to end. POST /v1/billing.setup_payment (autumn-js billing.setupPayment) opens a Stripe setup-mode checkout and returns { customer_id, entity_id?, url }; the hosted page at GET /checkout/setup/:sessionId captures a card (card_number, exp, both editable so a test can pick the brand) and redirects to success_url. As with the existing checkout flow, nothing changes on the customer until the checkout.session.completed webhook lands, modelled by POST /checkout/setup/:sessionId/settle (or the customer-wide POST /checkout/settle, which now settles setup sessions too). Settling matches real Autumn's surprising behaviour: a setup session only sets the default payment method when the customer has none, and never replaces an existing card, because Autumn's setup-checkout handler reads the current default first and re-sets that same card.
• Autumn hosted billing portal — POST /v1/billing.open_customer_portal now returns a URL that actually serves a page. GET /checkout/portal/:customerId shows the customer's current plan, the card on file (or "No payment method"), a form to update it, and a link back to the return_url the portal session was opened with (recorded in the new autumn.portals collection). POST /checkout/portal/:customerId/payment-method changes the card IMMEDIATELY, with no settle step, because real Stripe swaps the default inside the portal and Autumn reads the card live on every expand. This is how an application under test changes a card. Unknown customers 404.
• Autumn payment_method expand — customers.get_or_create honours expand: ["payment_method"], returning the Stripe PaymentMethod (id, type, card.brand, card.last4, card.exp_month, card.exp_year), and omitting the field entirely when there is no card or when expand does not ask for it. Settling a paid checkout also leaves a visa 4242 on file when the customer had no card, and customers can be seeded with a payment_method.