Do not offer API sign-in mode where it cannot work (webserver-served deployments)

When the WebUI is served by a **webserver**, `allowChangeSigninMode = true` still offers **API** on the login screen — but API mode cannot work against a webserver address. The user picks a mode that is guaranteed to fail.

## Why API mode cannot work through the webserver

Verified against the backend.ai source:

1. `/func/*` is session-only. **`get_api_session` (`src/ai/backend/web/auth.py`) raises 401 unless the request carries an authenticated web session holding a `keypair` token, then signs upstream with** that session's\*\* keypair — the caller's own keypair is never used. Confirmed empirically: a valid session cookie plus a deliberately garbage `Authorization` header still succeeds.
1. **Signatures are host-bound and the proxy does not rewrite them.** The manager will verify against the original URL when `X-Forwarded-URL` is present (`src/ai/backend/manager/api/rest/middleware/auth.py`), but **nothing in backend.ai sets that header** — the manager only reads it, for an external reverse proxy. A signature computed for the webserver host cannot validate at the manager.
1. **`POST /admin/gql` is not a route on the webserver.** The last route is the SPA catch-all `GET /{path:.*$`} (`src/ai/backend/web/server.py`), so a POST returns `405` with `Allow: GET,OPTIONS`.

API mode therefore requires a directly reachable **manager** endpoint. A team member reached the same conclusion in the session-max-count thread, describing API mode as "not going through the webserver ... because the endpoint has to be 8091" — though that remark was explicitly hedged as a guess, so it corroborates the finding rather than establishing it.

## What the user sees today

The failure is already reported at a reasonable level — `connectUsingAPI` catches and shows `error.CannotConnectToServer` ("Cannot connect to the server. Please check the endpoint address and network connection."). The CORS message only appears in the devtools console, so **no CORS wording belongs in the UI**.

The defect is narrower than the message: an option is presented that cannot succeed in this deployment.

## Proposal

Do not offer a mode that cannot work. When the WebUI is served by a webserver, hide the Session/API switch (or disable the API option). If a reason is shown at all, keep it in product language — the endpoint address is what the user can act on, not the transport error.

Worth confirming first: whether any shipped deployment legitimately serves the WebUI from a webserver while expecting users to point API mode at a separate manager address. If so, the switch should stay and the fix is limited to guidance.

JIRA Issue: FR-3562

Start at the login UI entry point that renders the Session/API switch and the connectUsingAPI flow. Compare how a webserver-served deployment is identified, and review the cited web/auth.py, manager/api/rest/middleware/auth.py, and web/server.py routes before deciding whether a separate manager address is supported. Done means the API choice is hidden or disabled only where it cannot work, with guidance kept product-focused.

Written by the indexing model from the issue text.