Clusters list reopens a saved edit draft as a new-cluster form #1852

When a cluster draft is saved in local storage (SavedClusterState), the clusters list redirects to the form, but it always sends the draft to /<org>/new-cluster (src/features/clusters/ClustersList.tsx, the if (savedClusterState) branch). A draft saved while editing a cluster carries clusterId (ClusterForm's onSaveStateForBillingRedirect stores { clusterId, ...values, skipToBilling: true }), so landing on the list with one reopens it as a create form: UpsertCluster reads the draft as default values, clusterId comes from the route params and is undefined, and the billing step offers Create New Cluster for what was an edit of an existing cluster.

The billing return page already gets this right: ProcessSetupIntent's navigateBack sends a draft with clusterId to ../../<clusterId>/edit and only other drafts to new-cluster.

How a user gets there: start an edit that changes capacity, reach the billing step, add a payment method whose confirmation redirects to an external page, and come back to the organization's clusters list some way other than Stripe's return URL (for example by abandoning that page and opening the org again). The draft is still saved, so the list redirects into a create form prefilled from the edit.

Expected: the list sends an edit draft back to that cluster's edit page, the same way the billing return page does. A draft whose cluster belongs to another organization probably should not redirect from this organization's list at all.

Found while fixing #1326 (#1851), which made this redirect replace its history entry but deliberately left its destination alone.

_{🤖 Generated by Anthropic Claude Code (Claude Opus 5.5); posted via @dawsontoth.}