Custom connector: authorization_endpoint from discovery metadata ignored — hardcoded /authorize used instead, causing 404

### MCP server URL

https://homeassistant.tailf1e017.ts.net/api/webhook/mcp_

### Where does the issue occur?

In the authorization screen from my server

### Transport used

streamable-http

### Client registration type

Dynamic Client Registration (DCR)

### SSE only: Does your server return the expected status code for POST requests?

Not applicable (my server does not use SSE)

### When did you last reproduce this?

31.08.2026, ca. 09:00 CEST (UTC+2)

### Browser and OS

Windows 10, Firefox

### Describe the issue

When connecting a custom connector to a self-hosted MCP server (Home Assistant / ha-mcp) via OAuth, Claude opens an authorize URL that is missing the path prefix specified in the server's own discovery metadata, resulting in a 404 on the authorization screen.

### Issue details

```shell
Adding this connector initially failed during automatic Dynamic Client Registration with:
"Couldn't register with [server]'s sign-in service. You can try again, or add an OAuth Client ID in the connector settings." (ofid_40835adb1c1115db, then ofid_e63178460fb742c0 on retry after a full server restart).

To isolate the cause, I manually replayed the discovery + registration flow with curl. All steps succeeded server-side (see Logs section below): protected resource metadata, issuer-specific authorization server metadata, and a manual POST to the registration_endpoint (201 Created).

I then removed the connector, re-added it, and supplied the client_id obtained from the successful manual registration. Clicking Connect opened:
https://homeassistant.tailf1e017.ts.net/authorize?response_type=code&client_id=hamcp-dcr-&redirect_uri=https%3A%2F%2Fclaude.ai%2Fapi%2Fmcp%2Fauth_callback&code_challenge=&code_challenge_method=S256&state=

After signing in with my Claude account, this returned 404.

The server's own discovery metadata (see Logs) specifies:
"authorization_endpoint": "https://homeassistant.tailf1e017.ts.net/api/mcp_proxy/oauth/authorize"

but Claude requested:
https://homeassistant.tailf1e017.ts.net/authorize

— i.e. missing the /api/mcp_proxy/oauth path prefix entirely.
```

### Expected behavior

Claude should use the exact authorization_endpoint value returned by the issuer-specific authorization server metadata document (as referenced by the protected resource metadata's authorization_servers field), rather than constructing or falling back to a path relative to the bare origin.

### Logs from your server

```shell
[2026-08-31 08:52:46 CEST] MCP handshake sanity check:
POST /api/webhook/mcp_ (Accept: application/json, text/event-stream)
→ 200 OK, valid initialize response with full serverInfo/capabilities

[2026-08-31 08:50:55 CEST] Protected resource metadata:
GET /.well-known/oauth-protected-resource/api/webhook/mcp_
→ 200 OK
{"resource": "https://homeassistant.tailf1e017.ts.net/api/webhook/mcp_", "authorization_servers": ["https://homeassistant.tailf1e017.ts.net/api/mcp_proxy/oauth"], "bearer_methods_supported": ["header"], "resource_documentation": "https://github.com/homeassistant-ai/ha-mcp"}

[2026-08-31 08:52:04 CEST] Issuer-specific authorization server metadata:
GET /.well-known/oauth-authorization-server/api/mcp_proxy/oauth
→ 200 OK
{"issuer": "https://homeassistant.tailf1e017.ts.net/api/mcp_proxy/oauth", "authorization_endpoint": "https://homeassistant.tailf1e017.ts.net/api/mcp_proxy/oauth/authorize", "token_endpoint": "https://homeassistant.tailf1e017.ts.net/api/mcp_proxy/oauth/token", "registration_endpoint": "https://homeassistant.tailf1e017.ts.net/api/mcp_proxy/oauth/register", "response_types_supported": ["code"], "grant_types_supported": ["authorization_code"], "code_challenge_methods_supported": ["S256"], "token_endpoint_auth_methods_supported": ["none"], "client_id_metadata_document_supported": true}

[2026-08-31 08:52:46 CEST] Manual DCR against the correct registration_endpoint:
POST /api/mcp_proxy/oauth/register {"client_name":"Claude","redirect_uris":["https://claude.ai/api/mcp/auth_callback"],"grant_types":["authorization_code","refresh_token"],"response_types":["code"],"token_endpoint_auth_method":"none"}
→ 201 Created, valid client_id returned

Note: the domain root /.well-known/oauth-authorization-server (no path suffix) also returns 200 OK but describes Home Assistant's own native auth system (/auth/authorize, /auth/token) — a different, unrelated authorization server. This may be relevant if Claude's discovery walk is falling back to that root document instead of the issuer-specific one, though the 404'd URL doesn't fully match either document's endpoints.
```

### Additional context

Server: self-hosted HA-MCP add-on (Home Assistant), exposed via Tailscale Funnel (not Cloudflare). MCP server version reported in initialize response: ha-mcp 8.4.0.
All curl tests run from an external Windows machine (not on the same network/tailnet as the server) to rule out DNS/geo-blocking issues — confirmed public reachability throughout.
Reference IDs collected across attempts: ofid_38c09f3449d4f3b5, ofid_40835adb1c1115db, ofid_e63178460fb742c0.