fix(openapi): fetch analyticsdata Discovery from the service host

[smrht]

Summary

analyticsdata (the GA4 Data API) is not listed in Google's central Discovery
directory, so the canonical directory URL answers 404 and importing the source
fails. Route it to its own host, the same override forms, keep and
photospicker already use.

One line in GOOGLE_DISCOVERY_SERVICE_OVERRIDES, plus the matching assertions.

Linked issue

Related to #1855. That issue asks for full Analytics Admin and Data presets and
notes both should "preserve their service-hosted Discovery URLs" — this PR is
only that Discovery part, which breaks today for anyone adding analyticsdata
as a custom Google OpenAPI source, preset or no preset.

Verification

Both URLs, checked live today:

$ curl -s -o /dev/null -w '%{http_code}\n' \
    'https://www.googleapis.com/discovery/v1/apis/analyticsdata/v1beta/rest'
404

$ curl -s -o /dev/null -w '%{http_code} %{size_download}\n' \
    'https://analyticsdata.googleapis.com/$discovery/rest?version=v1beta'
200 117897

The 404 body is {"error":{"code":404,"message":"Requested entity was not found.","status":"NOT_FOUND"}}. The service-hosted document reports name: analyticsdata, version: v1beta.

With the override applied on a self-hosted instance, a GA4 connection resolves
and analyticsdata.properties.runReport becomes callable; without it the source
never imports.

The added assertions fail on the unpatched map:

AssertionError: expected 'https://www.googleapis.com/discovery/…'
             to be 'https://analyticsdata.googleapis.com/…'
 Tests  1 failed | 15 passed (16)

and pass with the one-line change (27 passed across discovery.test.ts and
presets.test.ts).

• bun run format:check — all matched files correctly formatted (2061 files)
• bun run lint — 0 warnings, 0 errors
• bun run typecheck — 45/45 tasks successful
• bun run test — plugin-openapi and plugin-provider-service-split
  green (36/36 in the latter). A few apps/local migration-recovery and
  host-mcp stdio/daemon tests fail in my sandbox, but they fail the same
  way on an unmodified checkout of main and the failing set changes
  between runs, so they are environmental here rather than caused by this
  change. Happy to have CI be the judge.
• e2e — not run. No scenario exercises Discovery URL selection, and this is
  a pure URL-mapping change covered by the unit assertions above. Glad to
  add a scenario if you would prefer one.

Checklist

• Added a changeset (patch on @executor-js/plugin-openapi).
• Added tests for the new behaviour, in both normalization directions.
• No secrets, credentials, or private data in the diff.