…ot hold

These tests assert that a credential is *rejected*, which only means something
if the endpoint exists and something is there to reject it. Neither holds on
Unstract Cloud, and both went unnoticed because a missing endpoint fails in the
direction that looks like success.

Cloud main went red the moment #2207 landed. `copy_cloud_deps` overwrites the
OSS `settings/test.py` with a redirect to `test_cloud`, which derives from
`settings/cloud` — so `MCP_PLATFORM_SERVER_ENABLED = True` never reaches the
cloud suite, `urls_v2` leaves the route unmounted, and five of these tests 404.

The sixth is the reason this is a skip and not a deselect:
`test_bad_credentials_are_rejected` *passed* on cloud. A 404 satisfies "this
request is refused" exactly as well as the 401 it was written to assert, so it
reported green for auth that was never reached. Ignoring the file would have
kept that hidden; a skip names it.

Enabling the flag on cloud would not have fixed it either. The same
`test_cloud.py` drops `CUSTOM_AUTH_MIDDLEWARE` from the default test
`MIDDLEWARE`, and this view carries `permission_classes = []` and deliberately
does not re-authenticate — so the endpoint would have gone from unmounted to
unauthenticated, trading five failures for a different five.

So both preconditions are checked, and checked directly rather than by reading
`MCP_PLATFORM_SERVER_ENABLED`: the flag is what causes the mount in the OSS
URLconf, but it is not what these tests need. Asking for the route and the
middleware stays correct for any tree that mounts the server another way, and
the skip re-arms on its own if cloud ever runs this endpoint with auth.

The route probe resolves a path with no organization segment, unlike the URL
the tests request — tenant middleware strips the org from `path_info` before
resolution, so resolving the request URL as written 404s even on OSS.

Verified against real merged trees: OSS reports no unmet precondition and the
suite runs unchanged; the cloud tree reports the route reason with the flag off
and the middleware reason with it on. 198 unit tests still pass.

This does not change what ships. The deployment-scoped MCP server — the one
required for release — is mounted unconditionally in `api_v2/execution_urls.py`
and is unaffected.

Addresses review: skipping on a 404 can hide a genuine regression.

That is right, and it is the direction that matters. Where the org-scoped
server is meant to be enabled, an unmounted route is a bug — and the previous
version would have gone quiet exactly when it should have shouted, which is the
same failure this suite exists to catch, one level up.

So the flag now decides whether the server is expected here, and the route and
middleware become assertions rather than skip conditions:

  MCP_PLATFORM_SERVER_ENABLED off -> skip; the server is deliberately absent
  (Unstract Cloud ships it that way) and there is nothing to authenticate.

  MCP_PLATFORM_SERVER_ENABLED on  -> the route must resolve and
  CUSTOM_AUTH_MIDDLEWARE must be in MIDDLEWARE, or the suite fails and says
  which one is missing.

The middleware assertion is kept because the flag alone does not make these
tests meaningful: cloud's `test_cloud.py` drops CUSTOM_AUTH_MIDDLEWARE from the
default test MIDDLEWARE, and this view carries `permission_classes = []` and
does not re-authenticate. Enabling the flag there without the middleware would
move the endpoint from unmounted to unauthenticated — so if someone turns the
server on for the cloud suite, this fails with the reason rather than passing
against an open endpoint.

Verified in all four states: enabled and wired up runs; disabled skips; enabled
with the middleware dropped fails naming the middleware; enabled against a
URLconf without the mount fails naming the path. 198 unit tests still pass.