Add frontend routing to Geo GraphQL specific sites replicables

What does this MR do and why?

This adds replicable endpoints for each Geo site, to allow the primary to request this data from the tracking DB directly on any secondary site.

This is necessary for Geo proxying with unified URLs, as the web traffic will all be proxied to the primary, however we don't have projects/designs implemented in GraphQL so these don't yet work.

Related to #345420 (closed).

Resource type	Unified URL visit primary	Unified URL visit secondary	Separate URL with proxying visit primary	Separate URL with proxying visit secondary	Separate URL without proxying visit primary	Separate URL without proxying visit secondary
Projects	❌ warning about looking at replication data on primary	✅ render locally (bypass proxy)	❌ N/A - can't be proxied	✅ render locally (as current)	❌ not available before/after this MR	✅ render locally (as current)
Designs	❌ warning about looking at replication data on primary	✅ render locally (bypass proxy)	❌ N/A - can't be proxied	✅ render locally (as current)	❌ not available before/after this MR	✅ render locally (as current)
SSF	✅ render by primary (GraphQL proxy)	✅ render by primary (GraphQL proxy)	✅ render by primary (GraphQL proxy)	✅ render by primary (GraphQL proxy)	✅ not available before, can be rendered by primary now (no direct link though)	✅ render locally (as current)

Choices made/assumptions in this MR:

• The replication details button always redirects to the first replicable object type in SSF, to make it easier & consistent
• The replicable page knows about the current node, and a "target node" if present (i.e. from the primary, ID 3, I can look at the replication data for the Geo site ID 3)
• All requests on the replicables page will now use /api/v4/geo/graphql instead of simply /api/v4/graphql when there is no "target node", or the target node is the current node (as it will be served locally and bypass the proxy)
• Legacy routes for the SSF will redirect to the "new" full version if there's no ID present (/admin/geo/sites/:id/replication/:type)
• Projects and designs keep the old routes, /admin/geo/replication/{projects,designs}/* - this may be confusing, but allows us to allowlist them from being proxied, and there are also routes under those (i.e. reverify, resync operations) that may get too complex to rename in this MR and can be followed up afterwards IMO
• Route generation from secondaries projects/designs paths still works, because they only get rendered (bypassing proxy) locally so the target node ID will be the expected node (and clicking on those get to a page where this is proxied)
• Sidebar "Replication" button is now displayed for the primary too, to avoid confusion

Screenshots or screen recordings

Projects

current node	type	before	after
secondary	non-proxied, read-only
secondary	proxied, separate URLs
secondary	proxied, unified URLs
primary	looking at itself (/replication/projects)		(empty, no errors)
primary	looking at secondary (/sites/2/)	not possible

Designs

current node	type	before	after
secondary	non-proxied, read-only
secondary	proxied, separate URLs
secondary	proxied, unified URLs
primary	looking at itself (/replication/projects)
primary	looking at secondary (/sites/2/)	not possible

GraphQL data types (non-project & designs)

current node	type	before	after
secondary	non-proxied, read-only
secondary	proxied, separate URLs	(empty, despite data)
secondary	proxied, unified URLs	(empty, despite data)
primary	looking at secondary (/sites/2/)	not possible

How to set up and validate locally

1. Have GDK + Geo set up with unified URLs
2. Go to http://gdk.test:3001/admin/geo/sites/2/replication/merge_request_diffs and navigate to projects/designs as well & back, notice it's working on this branch
3. Go to http://gdk.test:3001/admin/geo/sites and click on the replication details button, notice it uses the selected site ID + first SSF objects

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.