Update the vendored Topology Service client gem for registry_address

What does this MR do and why?

Task 3 of cells-infrastructure/team#949, the Rails half: re-run scripts/update-topology-service-gem.sh so the vendored gitlab-topology-service-client gem carries ProxyInfo.registry_address and CellInfo.registry_address.

Topology Service gained an optional registry_address per cell, returned on the Classify response so the HTTP Router's registry shard can resolve a cell's container registry (topology-service!566, merged). The vendored copies go stale silently until someone runs the sync script, so this is that run.

Housekeeping, not a blocker. cells-mailroom/lib/cells/mailroom/cell_router.rb is the only Classify caller in the monorepo; it issues ClassifyRequest.new(type: :FIRST_CELL) and reads response.proxy.address. registry_address is a new field on an existing message, so that code is unaffected either way — nothing in lib/, app/ or ee/ constructs a ClassifyRequest at all.

What's in the diff

Both lib/proto/*_pb.rb changes are one line each: these files are serialized descriptors, so the registry_address field shows up inside the descriptor_data string rather than as reviewable Ruby. The source of truth is proto/cell_info.proto and proto/classify_service.proto in topology-service!566.

Gemfile.lock carries most of the line count and none of it relates to this change. The gem's .sync manifest includes Gemfile.lock, and the last sync was 267fb06, so this picks up topology-service's own renovate lock-file maintenance (c1782a9) along the way — grpc 1.80.0 → 1.83.1, google-protobuf 4.34.1 → 4.36.1 and friends. This lock file governs only bundling inside vendor/gems/gitlab-topology-service-client/; the Rails app resolves the gem as a path dependency through its own top-level Gemfile.lock, which is untouched.

REVISION points at ba1d221 on topology-service's main.

References

• Work item: cells-infrastructure/team#949 (task 3)
• Topology Service: topology-service!566 (merged)
• Design document: handbook!21159 (unmerged)
• Why the field is a response field rather than a target request argument: see !566 (merged)'s description. #949 (closed)'s own description still specifies the superseded design.
• Sibling: the TypeScript half of task 3 is gitlab-org/cells/http-router!1390 (merged)

Screenshots or screen recordings

Not applicable — no UI change.

How to set up and validate locally

1. Check out this branch.

2. Confirm the vendored gem still loads and the new field is on the message:

   cd vendor/gems/gitlab-topology-service-client
   bundle install
   bundle exec ruby -e 'require "proto/classify_service_pb"; \
     puts Gitlab::Cells::TopologyService::ProxyInfo.descriptor.map(&:name).inspect'
   # => ["address", "registry_address"]

3. Confirm the existing Rails caller is unaffected:

   cd cells-mailroom && bundle exec rspec spec/cells/mailroom/cell_router_spec.rb
   # => 20 examples, 0 failures

4. Confirm the vendored copy is a faithful sync rather than a hand-edit — it should print No changes to commit:

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

MR acceptance checklist

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