Read the CI log. One failure, and it's real — not flaky.

FAILURE
  api/billing/invoice.test.ts:88
  Expected 2 invoice line items, received 3.
  First red build: commit 4f2c9a1, merged 40 minutes ago.

CAUSE
  4f2c9a1 added a proration line item to invoice generation. Correct
  change. The test asserted an exact count and predates proration
  existing, so it was always going to break the first time anyone added
  a line type.

  It passed on the branch because the branch forked before 7bd3e02,
  which enabled proration by default. Neither commit is wrong; the
  combination is. Standard semantic conflict — CI on each branch
  couldn't have caught it.

MINIMAL FIX
  The assertion is testing the wrong thing. It should assert the
  subscription line is present and correct, not that exactly two lines
  exist — the count is incidental and will break again next time.

  - expect(invoice.lineItems).toHaveLength(2)
  + expect(invoice.lineItems).toContainEqual(
  +   expect.objectContaining({ type: 'subscription', amount: 4900 })
  + )

TEST ADDED — covers the gap that let this through
  A case asserting the proration line appears when a mid-cycle plan
  change occurred. That behavior shipped in 4f2c9a1 with no test, which
  is why the only signal was an unrelated assertion breaking.

SCOPE — deliberately not touched
  The other 11 exact-length assertions in this file have the same
  latent fragility. Not fixing them here: unrelated to the red build,
  and a 12-assertion refactor on a hot main is how one red build
  becomes two. Worth a follow-up.

VERIFY
  Suite green locally, 3 consecutive runs. Ready to push.