server: add HTTP API for user management

## Feature Request

### Problem

The TiDB Cloud now needs a supported way to manage temporary/internal database users without relying on direct SQL execution by a privileged admin account.

In particular, `cloud_admin` can no longer safely or reliably perform operations such as:

- create temporary session users
- reset a user password and hand the new secret back to the control plane
- grant system roles such as `diagnoser_role`
- delete stale or zombie users

Today, this requires elevated SQL privileges and operational workarounds. It also lacks a narrow, auditable API surface.

### Proposed Feature

Add internal user admin APIs to the TiDB status server, gated by mTLS-authenticated requests only.

Proposed endpoints:

1. `POST /v1/internal/users`
- create a new internal database user
- request body:
```json
{
"username": "tmp_user_session_12345",
"password": "temporary_strong_password_here"
}
```
- response:
```json
{
"status": "success",
"username": "tmp_user_session_12345",
"created_at": "2026-02-04T10:00:00Z"
}
```

2. `POST /internal/v1/users/{username}/reset-password`
- generate and set a new secure random password immediately
- request body:
```json
{
"reason": "Security remediation - compromised session",
"expire_now": true
}
```
- response:
```json
{
"status": "success",
"new_password": ""
}
```

3. `POST /internal/v1/users/{username}/roles`
- grant system roles to a user
- request body:
```json
{
"roles": ["diagnoser_role"]
}
```

4. `DELETE /internal/v1/users/{username}`
- permanently remove a user
- return `409` if the user cannot be deleted, for example when it is the last remaining user

### Security Requirements

These APIs are highly privileged and should only be available over mTLS-authenticated connections.

Expected behavior:
- requests without a valid client certificate return `403 Forbidden`
- all accesses should be audit logged
- sensitive values such as generated passwords must not appear in audit SQL text or logs

### Expected Benefits

- removes the need for broad SQL user-management privileges in control-plane components
- provides a narrow and explicit administrative surface
- improves auditability for internal user lifecycle operations
- supports SQL proxy temporary-user workflows directly

### Additional Notes

The API is intended for internal platform/control-plane use rather than general SQL client access.