Claim `reply_key` in Topology Service for Sent Notifications backward compatibility
## Problem Statement
In the [Cells architecture](https://gitlab.com/groups/gitlab-com/gl-infra/-/work_items/1815), legacy unsubscribe URLs (`/-/sent_notifications/<reply_key>/unsubscribe`) and incoming email reply addresses (`incoming+<reply_key>@gitlab.com`) may persist in user inboxes for up to 2 years. The HTTP Router cannot determine which Cell owns a given `reply_key` without a lookup in the Topology Service.
To ensure backward compatibility, each existing `reply_key` from the `p_sent_notifications` table must be **claimed** in the Topology Service, mapping it to the Cell that owns the corresponding notification record. This allows the HTTP Router to resolve legacy URLs and email reply addresses to the correct Cell without requiring the new namespace-scoped URL format.
This work complements:
- https://gitlab.com/gitlab-org/gitlab/-/issues/584327 — which introduces the new namespace-scoped unsubscribe route going forward.
- https://gitlab.com/gitlab-org/gitlab/-/issues/592190 — which updates the HTTP Router to support path-based routing for the new URL pattern
## Exit Criteria
- [ ] Existing `reply_key` values from `p_sent_notifications` are claimed in the Topology Service, mapping each key to its owning Cell
- [ ] The HTTP Router can resolve legacy `/-/sent_notifications/:reply_key/unsubscribe` URLs via Topology Service claim lookup
- [ ] Legacy incoming email reply addresses (`incoming+<reply_key>@...`) can be resolved to the correct Cell via the claim
- [ ] Automated testing covers both backfill of existing keys and claiming of new keys
issue