ref(api): type fetchMutation urls with getApiUrl

[ryan953]

fetchMutation took its url as a plain string, so every call site built a
path by interpolation and nothing checked that the result was a real endpoint.
This narrows the field to the branded ApiUrl that getApiUrl() returns and
converts the remaining call sites, which turns a typo or a renamed route into a
type error instead of a 404 at runtime.

The brand is what does the work. It is not assignable from string, so the
compiler finds every call site that still interpolates — including the two that
carried a query parameter inside the path (?_=<signature> on the unsubscribe
pages, ?rerun=true on the preprod build comparison). Those move to
options.query, since appending to a branded url widens it back to string and
no longer compiles.

getExternalActorEndpointDetails is deleted. It took a collection endpoint and
appended the mapping id for PUT, which only works on an opaque string. Each
getBaseFormEndpoint now returns the finished url for its own resource and the
form only chooses the method.

Two entries are added to knownGetsentryApiUrls for the admin
billing-platform-migration and delete-billing-metric-history endpoints, which had
no typed path yet. The latter had also been requesting /api/0/customers/...,
which double-prefixes the client's own /api/0 base; it now uses the same
unprefixed path as every other admin view.

No feature flags are involved — this is a type change plus the call sites it
forces.

Review focus

The external actor mapping forms are where behaviour can actually move, because
url construction shifted out of the shared helper and into each caller. The
second commit is the interesting one: getBaseFormEndpoint must be called with
the resolved mutation data, not the original mapping row, since the team
endpoint derives its slug from whichever team was just selected and the callback
needs the id to address an existing mapping. Worth confirming that reading — the
existing suite covers both the create-via-modal and inline-edit paths.

IntegrationExternalUserMappings had no id-in-path branch at all, so it gained
the one the teams side already had. There is no spec file for that view, so that
particular path is covered by reading rather than by a test.

[github-actions]

📊 Type Coverage Diff

Metric	Before	After	Delta
Coverage	95.55%	95.55%	±0%
Typed	140,055	140,052	🔴 -3
Untyped	6,519	6,521	🔴 +2

🔍 2 new type safety issues introduced

Type assertions (as) (2 new)

File	Line	Detail
static/app/views/settings/organizationIntegrations/integrationExternalMappingForm.tsx	188	as ExternalActorMappingOrSuggestion — fullData as ExternalActorMappingOrSuggestion
static/app/views/settings/organizationIntegrations/integrationExternalMappingForm.tsx	273	as ExternalActorMappingOrSuggestion — fullData as ExternalActorMappingOrSuggestion

This is informational only and does not block the PR.

[ryan953]

Parsing the queryKey moves into the useIntentData hook, so we can use ApiQueryKey as the prop type instead of the old string.

[ryan953]

Here's where the type is enforced going forward!

[ryan953]

This is the place with the 'most' change in the PR.

Before we were accepting mapping and getBaseFormEndpoint() and calling them ourselves. Then we'd call getExternalActorEndpointDetails() which could potentially append an id to the end of the url.

All that gets streamlined. Now it's the job of each getBaseFormEndpoint() function to return a correct url, with or without the id appended. Therefore we don't need getExternalActorEndpointDetails anymore either.

there's a only two real files that implement getBaseFormEndpoint. They each accept the mapping parameter and append an id if it's passed in.