server: add a redacted global variables HTTP API for NextGen

## Feature Request

**Is your feature request related to a problem? Please describe:**

NextGen operators need to inspect the global system variables of the keyspace served by a TiDB instance through its status HTTP API, without opening a SQL connection. Returning variable values directly would expose credentials and other sensitive configuration, so this diagnostic endpoint must redact sensitive values independently of log-redaction settings.

This API would improve diagnosis by giving operators and diagnostic tools a convenient way to collect the current global-variable values alongside logs and metrics. That context can help identify unexpected settings, compare configuration across instances or keyspaces, and investigate configuration-related performance or behavior issues, while keeping sensitive values redacted.

**Describe the feature you'd like:**

Add a read-only `GET /variables/global` endpoint on the status port of NextGen TiDB instances, available for both SYSTEM and tenant keyspaces. Return a JSON object mapping variable names to string values for the current keyspace, rather than aggregating across keyspaces.

- Follow `SHOW GLOBAL VARIABLES` scope and no-op-variable selection, and omit variables hidden by SEM v1 or v2.
- Use the existing global-variable getters so runtime hooks and defaults are respected.
- Add explicit sensitivity metadata to system variables. After reading a value, replace non-empty sensitive values with the literal `******` and preserve empty values as empty strings. Do not provide a raw-value option.
- Cover embedding API keys, LDAP bind passwords, configuration and trace payloads, initialization SQL, and password dictionaries. Custom variable authors must opt in to sensitivity metadata.
- For `tidb_cloud_storage_uri`, reuse the existing getter's `ast.RedactURL` behavior: retain the URI's bucket, path, and non-secret options while redacting recognized credential query parameters, consistent with the SQL getter. Keep an empty URI empty.
- Return `Cache-Control: no-store` and a generic HTTP 500 on read failures, without partial results or underlying error details that could contain secrets.
- Keep the endpoint absent from classic TiDB and leave SQL variable semantics unchanged.

**Describe alternatives you've considered:**

`SHOW GLOBAL VARIABLES` remains suitable for SQL clients, but it requires a SQL connection and does not provide this HTTP diagnostic interface. Reading `mysql.global_variables` directly would miss runtime getter behavior and defaults and would require separate sensitive-value handling.

**Teachability, Documentation, Adoption, Migration Strategy:**

Document the endpoint in `docs/tidb_http_api.md`, including its NextGen-only scope, JSON response format, redaction contract, and custom-variable metadata requirements. Example usage:

```sh
curl http://{TiDBIP}:10080/variables/global
```

This is an additive operator diagnostic API and requires no migration. It inherits the status port's trusted access controls rather than authenticating SQL users; status-port access must remain restricted to trusted operators.

Start with the NextGen status-port handler and existing global-variable getters, including the tidb_cloud_storage_uri getter's ast.RedactURL behavior, then trace how sensitivity metadata and SEM visibility are represented. Update docs/tidb_http_api.md and verify that GET /variables/global returns the scoped redacted JSON response, no-store headers, and generic failures without changing classic TiDB or SQL semantics.

Written by the indexing model from the issue text.