[Bug] Hubble lacks a secure query-only compatibility mode for authenticated Server 1.5

### Bug Type (问题类型)

rest-api (结果不合预期)

### Before submit

- [x] I searched the existing issues and found no equivalent report.

### Environment (环境信息)

- HugeGraph Server: 1.5.0 (Core 1.5.0, REST API 0.71.0.0)
- Reproduction Hubble/Toolchain baseline: 60df3c51
- Current upstream PR target: be7ef3ae
- Authentication: StandardAuthenticator enabled
- Deployment: standalone, DEFAULT / hugegraph
- OS: macOS
- Browser: Google Chrome
- Data size: not data-dependent

### Expected & Actual behavior (期望与实际表现)

After entering credentials that are valid for an authentication-enabled HugeGraph Server 1.5, Hubble cannot establish a session. The current standalone login path assumes the modern `/auth/login` token endpoint, while Server 1.5 requires `/graphs/{graph}/auth/login` and subsequent graph requests use Basic authentication.

A simple Basic-auth fallback is not sufficient: if the stored credential were supplied to every existing Hubble controller, direct API calls could still reach unsupported management or mutation operations. The compatibility mode therefore needs to be explicit, version-bounded, query-only, and enforced on the backend rather than only by hidden frontend controls.

## Steps to reproduce

1. Start HugeGraph Server 1.5.0 with `StandardAuthenticator` enabled.
2. Start the pre-compatibility Hubble baseline with `server.auth.enabled=true` and `server.direct_url` pointing to that server.
3. Open the Hubble login page.
4. Enter credentials already verified against the Server 1.5 graph-scoped auth endpoint.
5. Submit the login form.
6. Observe that Hubble stays on `/login` and reports `Request failed: Failed to login HugeGraph Server`.

## Before evidence

### Step 1: open the Hubble login page

### Step 2: enter credentials verified against Server 1.5

### Step 3: submit the form

## Actual behavior

Hubble cannot log in to authenticated Server 1.5. There is no explicit compatibility policy, no bounded Basic-auth session, and no server-side query-only boundary.

## Expected behavior

Hubble should keep `strict` as the default for Server 1.7+, while an operator may explicitly select `legacy-query` for authenticated Server 1.5. In that mode:

- detect and accept only the tested Server 1.5 range;
- use the graph-scoped legacy login endpoint;
- retain the Basic credential only in the server-side Hubble session with a short TTL and clear it on logout or successful password change;
- allow only login/logout/context, profile read, self password change, and synchronous Gremlin;
- reject unsupported endpoints server-side with a localized business error;
- expose an auth context that declares the fixed legacy graph and query-only capabilities;
- preserve the active session when password validation or the password update fails.

PD mode and broader Server 1.5 management compatibility are outside this issue.

### Vertex/Edge example (问题点 / 边数据举例)

```javascript
N/A — this issue is not dependent on vertex or edge data.
```

### Schema [VertexLabel, EdgeLabel, IndexLabel] (元数据结构)

```javascript
N/A — this issue concerns authentication and backend capability boundaries.
```

Start by tracing Hubble's login page and standalone login flow, including the modern /auth/login endpoint and the Server 1.5 /graphs/{graph}/auth/login endpoint. Done means an explicit, version-bounded legacy-query mode supports only the listed query-safe operations, keeps the session behavior intact on failed password actions, and enforces unsupported endpoints server-side.

Written by the indexing model from the issue text.