set_graphql_schema_introspection_options / disabled_for_roles has no runtime effect on v2.44.0 (Pro image)

Applying the documented control via the metadata API succeeds and persists, but does not change runtime behaviour:

```
POST /v1/metadata
{"type":"set_graphql_schema_introspection_options",
"args":{"disabled_for_roles":["public"]}}
→ {"message":"success"}

export_metadata → "graphql_schema_introspection": {"disabled_for_roles": ["public"]}

reload_metadata → {"is_consistent":true,"message":"success"}
```

After all of the above, an unauthenticated introspection query still succeeds:

```
curl -s -X POST https:///v1/graphql \
-H 'Content-Type: application/json' \
-d '{"query":"{__schema{types{name}}}"}'
→ full type list
```

Role resolution and row-level permissions otherwise work correctly: an anonymous request resolves to the configured unauthorized role (`HASURA_GRAPHQL_UNAUTHORIZED_ROLE`), and permission-scoped queries against that role return empty/forbidden results as expected. Only introspection ignores the `disabled_for_roles` setting.

Version: Hasura GraphQL Engine v2.44.0 (Pro edition image).

Can you confirm whether the Pro edition handles `disabled_for_roles` differently, or whether `HASURA_GRAPHQL_ENABLE_INTROSPECTION` (an env-only flag) is required instead? If it is env-only, it would help to call that out in the metadata API documentation, since the metadata call currently reports success without closing introspection.

Start by reproducing the metadata API sequence and unauthenticated query against the v2.44.0 Pro image, then compare it with HASURA_GRAPHQL_ENABLE_INTROSPECTION. Trace the /v1/metadata, export_metadata, reload_metadata, and /v1/graphql entry points; done means the setting affects introspection or the metadata documentation clearly explains the env-only behavior.

Written by the indexing model from the issue text.