normalizeResourceUrl mangles custom-scheme resource URLs (gitlab://x → https://gitlab://x)

[noises1990]

Description

normalizeResourceUrl() in workshop-frontend/src/resourceMatching.ts prepends https:// to any resource URL that does not already start with http(s)://:

if (normalized && !/^https?:\/\//i.test(normalized)) {
  normalized = 'https://' + normalized
}

Custom-vendor resources with their own schemes are first-class elsewhere in the platform — a blueprint's gatekeeperName + typeUrlPattern may reference any GATEKEEPER_* vendor, and matchesResourceUrlPattern() deliberately handles non-special schemes — but any custom-scheme URL passing through the blueprint flow gets mangled on the way to the backend: our gitlab://inspekter-estate reaches account.getGatekeeperClassFor() as https://gitlab://inspekter-estate (both via the auto-suggestion path and via handleSaveActiveBinding), and the UI displays the mangled form ("Using: https://gitlab://inspekter-estate").

Observed on our pinned build (6478a144) and still reproducing as of 2026-08-30; the regex is unchanged on current main.

Steps observed

1. Deploy a custom gatekeeper whose vendor advertises a custom-scheme resource, e.g. getSupportedResources() → { urlPattern: "gitlab://*" }.
2. Build a blueprint with a binding declaring typeUrlPattern: "gitlab://*", resourceUrl: "gitlab://inspekter-estate".
3. Import the blueprint and save the binding.
4. The vendor's getGatekeeperClassFor() receives https://gitlab://inspekter-estate; without a vendor-side workaround the bind fails (in our case: This gatekeeper serves gitlab:// resources, not https://gitlab://inspekter-estate), and the UI shows the mangled URL.

Expected behavior

Prepend https:// only when the URL has no scheme at all — e.g. test /^[a-z][a-z0-9+.-]*:\/\//i instead of /^https?:\/\//i.

Workaround we use

Our vendors' getGatekeeperClassFor() strips a leading https:// when it fronts the vendor's own scheme. That makes binding work, but the mangled form still persists in stored specs and in the UI, so it's tolerance rather than a fix.

Since the change looks like a one-line regex swap, we're happy to send it as a small PR per CONTRIBUTING.md if that's the direction you'd want — otherwise this is just the report.