feat(cells): Add option to route org listing through control silo

[lynnagara]

Adds the cells.use-control-org-listing option flag. When enabled, the org listing control feature is exposed to the UI, so it can route requests to the new endpoint.

This PR just registers and wires the option, no traffic is moved yet.

The frontend code that uses this option is in #117116

[sentry]

Bug: The feature flag organizations:use-control-org-listing is implemented via options.get(), bypassing the standard features.has() registration pattern, which harms discoverability and maintainability.
_{Severity: LOW}

Suggested Fix

Register organizations:use-control-org-listing as a feature in the feature manager (e.g., src/sentry/features/temporary.py) and use the standard features.has("organizations:use-control-org-listing", ...) check to expose it to the client, aligning it with existing patterns.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: src/sentry/web/client_config.py#L230-L231

Potential issue: The feature flag `organizations:use-control-org-listing` is implemented
by directly checking an option with `options.get()`. This bypasses the standard pattern
of registering features in the feature manager (e.g., in
`src/sentry/features/temporary.py` or `src/sentry/features/permanent.py`) and checking
them with `features.has()`. This architectural inconsistency makes the feature flag
undiscoverable to developers and automated tooling that rely on the feature manager for
auditing or analytics. While functionally correct, it introduces maintenance overhead
and potential for developer confusion, as it deviates from how other client-side
features are managed.

_{Did we get this right? 👍 / 👎 to inform future reviews.}

[markstory]

That's ok, this isn't actually an org scoped feature.