Vendor the Topology Service client's registry_address

What does this MR do and why?

Task 3 of cells-infrastructure/team#949, the http-router half: re-vendor the generated Topology Service TypeScript client so it carries ProxyInfo.registry_address, and widen the hand-written ClassifyResponse that the router actually reads Classify through.

Two commits:

1. scripts/update-topology-service-client.sh output — vendor/gitlab-topology-service-client/ gains registryAddress?: string on ProxyInfo and on CellInfo, plus the REVISION bump to ba1d221.
2. The same field on ClassifyResponse.proxy in src/topology_service/types.d.ts. That interface is hand-maintained and narrows proxy to just address, so without this the registry shard cannot read the field without casting.

The Topology Service change is not the one #949's description specifies. #949 still describes design A — a TargetType enum and a target argument on ClassifyRequest, the resolved target echoed back, and NOT_FOUND for a cell without a registry. Topology Service !566 implemented design B instead: the request is unchanged and ProxyInfo simply gains a second, disjoint address field. So there is no target to thread through proxyByClaim and the three buildXClaimHandler factories — this MR is one optional field and no call-site churn.

What design B costs the caller, and why it shows up in this diff: because one Classify response serves both web and registry callers, the service cannot tell which address the caller came for, so there is no server-side NOT_FOUND for a cell with no registry — it returns PROXY with the field empty. The miss belongs to the caller. That contract (absent means miss, never fall back to address, which serves web traffic on a different endpoint) is restated on the type, and on the GITLAB_PROXY_HOST fallback in src/topology_service/classify.ts, which deliberately leaves the field unset so a registry caller fails closed there too.

Nothing reads the field yet. Wiring the registry shard to it is #882.

References

• Work item: cells-infrastructure/team#949 (task 3)
• Topology Service: topology-service!566 (merged) — merged, so this sync is against its main
• Consumer: #882
• Design document: handbook!21159 (unmerged; its Topology Service section was rewritten to design B)
• Sibling: the Ruby gem half of task 3 is gitlab-org/gitlab!259156 (merged)

How to set up and validate locally

1. Check out this branch and install dependencies:

   npm ci

2. Type-check — this is the check that actually proves the hand-written type and the vendored generated type agree:

   ./.lefthook/pre-commit/type-check.bash
   npx prettier --check src/
   npx eslint src/

3. Run the suite. No behaviour changed, so every existing test should still pass:

   npx vitest run

   37 files, 459 tests passed locally.

4. Confirm the vendored copy really is a faithful sync rather than a hand-edit:

   ./scripts/update-topology-service-client.sh

   It should print No changes to commit.

The vendored diff is small because the last sync (e704727) was recent; no unrelated client churn came along with it.

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.