Follow-up on the fast-forward-renewal issue

Follow-up on the fast-forward-renewal issue — found something more specific, and double-checked the docs before flagging it.

On a fresh subscription (subscription_6tKL23V4LxBFtnk4Cgo9fV, never touched before), I called:

POST /v1/test-helpers/subscriptions/subscription_6tKL23V4LxBFtnk4Cgo9fV/fast-forward-renewal {"paymentStatus": "failed", "failureReason": "insufficient_funds"}

Response: 200 OK, subscription completely unchanged (nextRenewalAt, renewedAt identical to before).

A few seconds later, my webhook endpoint received order.paid for a brand new order (order_Twn3GDvnMpqhK8XnLZHXJ2, created 2026-09-25T15:38:34Z) tied to that same subscription — a real successful payment, with no order.payment_failed at any point. So requesting a failed-payment simulation produced a successful paid order instead.

On top of that, GET /v1/subscriptions/{id} still shows renewedAt: null even though a paid order now exists for it — so Order and Subscription end up out of sync too.

I checked your docs for the test-helpers endpoint before reporting this — the only documented deviation is a 409 when "a renewal produced no payable order, or whose payment has already settled." This subscription was a completely normal active one with a real future renewal due, so it should be the happy path, not that edge case.

This makes dunning/payment-recovery testing unusable right now — real blocker for us. Happy to send raw webhook payloads or anything else that helps debug.