Draft: Restore controller-matched route pairing (follow-up from !249936)

What does this MR do and why?

Restores the controller/action-matching check in Routing::OrganizationsHelper::MappedHelpers.build_route_pairs, pulled out of !249936 (merged) to unblock it.

Context: !249936 (merged) pairs a global route with its /o/:organization_path counterpart by name, so Current.data_context/the request's URL can automatically switch between them. Pairing by name alone incorrectly pairs routes that share a naming convention but are deliberately separate features - e.g. instance admin vs organization admin, which are being split into separate controllers. A controller/action-matching check (added in 930c98e36484) excluded these mismatched pairs automatically, but it also blocked a case it wasn't meant to: admin-area views intentionally reuse the same auto-nesting across the instance-wide and organization-scoped admin areas. That reuse was flagged in review - see !249936 (comment 3717787915).

This MR is a placeholder for that logic and the open design question, not a ready-to-merge fix - it currently just restores the exact same check, which reintroduces the same over-exclusion for the admin-area reuse case. Open questions to resolve before merging:

• Does the eligibility check need to distinguish "genuinely different controllers" from "different controllers intentionally sharing a view/nesting pattern," and if so, how?
• Should the check gate only Current.data_context (the ambient, inescapable rule), while the request's own URL (safe by construction - it only nests when already on that URL) applies regardless of controller match?
• Does this depend on whether Organizations that own instance admin users stay non-isolated (the operational mitigation agreed for !249936 (merged)), or should it work independently of that?

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist.