[mattdjenkinson]

Summary

Fixes #118. A customer's first card could finish setup without becoming the billing account's default, which left the organization stuck short of onboarding. The portal designates the card default as soon as it turns Active. The BillingAccount webhook checked the card through the manager's cache, which can lag the API by about a second, so it rejected the request as if the card were still AwaitingConfirmation. Nothing retried.

Either change below closes the bug on its own. Together they also cover a browser that leaves before it designates the card.

• The webhook reads the card from the API server. defaultPaymentMethodRef is now validated with mgr.GetAPIReader(), as the BillingArrangement webhook already does. It costs one GET on a rare write. The comment on ValidateBillingAccountDefaultPaymentMethodRef claimed it already read the live API, so that's corrected too.
• The controller sets the default for a first card. When an account has no default and exactly one Active payment method, the BillingAccount controller makes that card the default.
  • An existing default is never replaced.
  • With several Active cards and no default, the customer chooses.
  • The patch carries the account's resourceVersion, so it can't overwrite a default someone set at the same moment.
• New index: PaymentMethods are indexed by billing account for the controller's lookup.

Behaviour changes

• If staff clear the default on an account with a single Active card, the controller sets it straight back. The portal isn't affected: it removes a card by deleting it, never by clearing the default first.
• The existing payment-method-lifecycle e2e still passes. The controller may now set the default before the test links it, and applying the same ref is a no-op. I updated that step's description.

Tests

• Webhook unit test: the cache holds the card as AwaitingConfirmation while the API server has it Active. Without the fix it fails with the same message as the production denial.
• Envtest specs:
  • the first Active card becomes the default
  • an existing default stays when another card turns Active
  • no default is picked when several cards are Active
• New payment-method-default chainsaw test: covers the same cases on a real cluster, including setting a card Active and immediately designating it default. On kind the cache usually catches up within milliseconds, so the unit test is the reliable guard against a regression.

go test ./... (including envtest) and golangci-lint pass locally. The chainsaw tests haven't been run locally, so CI is their first run.

Not in this PR

The PaymentMethod delete webhook also checks the account's default through the cache. A card deleted moments after it became the default could get past that check. It's the same class of bug, so I'm leaving it for a follow-up.

[mattdjenkinson]

@JoseSzycho @scotwells could you take a look at this please?

[JoseSzycho]

@mattdjenkinson sure, taking a look in the next minutes