feat(deployments): make compute provider picker configurable

[rossnelson]

What

Makes the serverless worker compute provider picker configurable by the consumer via a new computeProviders prop, threaded from the page components (serverless-worker-create, worker-deployment-version-create, worker-deployment-version-edit) down through the forms into compute-provider-picker.svelte.

Each entry controls one provider:

export type ComputeProviderOption = {
  value: ComputeProviderValue;   // 'lambda' | 'cloud-run'
  disabled?: boolean;            // grey out
  disabledReason?: string;       // badge text explaining why
  hidden?: boolean;              // omit entirely
};

This supports both UX options in COM-193, chosen per call by the consumer: grey out incompatible providers with a reason, or hide them.

Why

For COM-193, compute options need to be restricted by the namespace cell's cloud type (Lambda on AWS, Cloud Run on GCP). This repo has no concept of cloud type and shouldn't, so the picker is made configurable and the consumer (cloud) decides what to offer per namespace.

Behavior

• When computeProviders is omitted, the picker keeps its current behavior: Lambda enabled, Cloud Run gated on the serverScaledProviderCloudRun capability with a "Coming Soon" badge. Self-hosted usage is unchanged.
• The picker auto-selects the first available provider when the current selection is not offered, so a restricted namespace cannot submit an unavailable provider.
• Added a Storybook story covering default, grey-out (AWS/GCP), hide-incompatible, and cross-cloud states.

Follow-up (not in this PR)

Cloud needs to compute the computeProviders array from the namespace cell and pass it into these page components. That cloud-type logic lives on the cloud side.

Testing

• pnpm check clean
• pnpm lint clean
• pnpm test all pass

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
holocene	Ready	Preview, Comment	Jul 13, 2026 7:22pm

[tegan-temporal]

Suggested change

	const selectable = visibleProviders.filter((option) => !option.disabled);
	if (selectable.length && !selectable.some((o) => o.value === provider)) {
	provider = selectable[0].value;
	}
	if (visibleProviders.some((option) => option.value === provider)) {
	return;
	}
	const fallback = visibleProviders.find((option) => !option.disabled);
	if (fallback) {
	provider = fallback.value;
	}

do we always to want reset the provider even if it's a valid, but currently disabled option? It seems like a non-obvious behavior to silently change the provider without user interaction if the provider exists 🤔

[rossnelson]

Good call, I updated this so we no longer reactively change the provider after the form mounts. A currently selected provider is preserved if it’s still visible, even when disabled. If it’s hidden or absent, the form selects the first visible enabled provider during initialization instead. I added tests for those cases and pushed the update.