Support user-based authentication for InfluxDB 3 Enterprise

Problem

The MCP server authenticates to InfluxDB with a single static token read from the environment at startup. Whatever that token can do, every agent session can do. There is no user identity, no per-session permission boundary, and no way to attribute actions to a person. On a shared server, one leaked or over-privileged token exposes everyone.

InfluxDB 3 Enterprise supports user authentication: a client exchanges a username and password for a short-lived access token plus a refresh token (POST /api/v3/authorize, POST /api/v3/authorize/refresh). The MCP server cannot use this today, because it treats the token as immutable configuration.

Goals

• The server can authenticate as an Enterprise user with INFLUX_DB_USERNAME and INFLUX_DB_PASSWORD, and all operations run with that user's permissions.
• Token lifecycle (login, proactive refresh before expiry, re-login when the refresh token is rejected) is handled inside the server. The agent never sees or handles token material.
• Static-token configuration keeps working unchanged for all product types.
• Ambiguous configuration (both a token and credentials set) fails at startup with a clear error instead of silently picking an identity.
• Credentials and tokens stay in memory, are never written to disk, and never appear in logs or error messages.

Scope

• New env vars INFLUX_DB_USERNAME / INFLUX_DB_PASSWORD, with validation rules for Enterprise (exactly one auth method) and an error when credentials are set for other product types.
• A new auth service owning login, refresh, and re-login, with coalescing so concurrent tool calls share one refresh.
• HTTP client resolves the token per request; one retry after a forced refresh on 401.
• The SDK query/write client is rebuilt when the token rotates.
• The existing status resource reports auth mode (token or user) and username — no secrets.
• No new MCP tools.

Out of scope

• User and role management tools (user CRUD, role assignment)
• OAuth device-code login
• Initial-user bootstrap and password-reset endpoints
• InfluxDB 3 Core (the gate is per product type; Core can be added when it supports these endpoints)

Trace the environment-variable validation, HTTP client, SDK query/write client, and existing status resource described in the issue. Start by understanding the current static-token flow, then review the Enterprise authorize and refresh endpoints. Done means user authentication, refresh and retry behavior, static-token compatibility, configuration errors, secret handling, and auth status reporting are covered without adding MCP tools.