buildUrl silently drops the baseUrl path segment for absolute step paths

[eaarranz]

Issue Summary

buildUrl in packages/integration-platform/src/runtime/check-context.ts composes request URLs with new URL(path, base || baseUrl). Per the WHATWG URL spec, an absolute path (/servers) replaces the entire path of the base — so a manifest with baseUrl: "https://api.hetzner.cloud/v1" and a step path /servers requests https://api.hetzner.cloud/servers (the /v1 is silently dropped), which returns the provider's 404 (api route not found).

The built-in code manifests avoid this by convention (version lives in the path, e.g. Vercel's /v9/projects), but nothing validates or documents it, and dynamic-integration authors hit it blind — the failure mode (provider 404) gives no hint that the base path was discarded.

Steps to Reproduce

1. Create a dynamic integration with baseUrl: "https://api.hetzner.cloud/v1".
2. Add a check step with "path": "/servers".
3. Connect with a valid token and run the check.

Actual Results

• HTTP 404: Not Found – {"error": {"message": "api route not found", "code": "not_found"}} — the request went to https://api.hetzner.cloud/servers.

Expected Results

Either of:

• buildUrl joins base path + step path explicitly (e.g. concatenating pathnames) so baseUrl path segments survive; or
• schema validation / docs state clearly that baseUrl must not contain a path and API versions belong in step paths.

Technical details

• Self-hosted Comp, runtime as of a 2026-07-29 checkout of main.
• One-line repro: new URL('/servers', 'https://api.hetzner.cloud/v1').toString() → 'https://api.hetzner.cloud/servers'.

Evidence

• Hit in production while building a Hetzner dynamic integration; moving the version into the step paths (/v1/servers) fixed all requests immediately. Can attach failing run logs with the provider 404 body.

[linear]

COMP-289

[eaarranz]

We have a fix worked out for this one too. Two options, your call:

1. Behavioral: explicit pathname joining in buildUrl so the base path survives absolute step paths (…/v1 + /servers → …/v1/servers). Slight behavior change for any manifest that (knowingly) relies on path replacement — we found none among the shipped manifests.
2. Guardrail: keep the current behavior but reject/warn on baseUrl containing a path segment at manifest validation time, and document "API versions belong in step paths".

Happy to open a PR against dev for whichever you prefer, with tests — just say the word.