Qdrant connector ignores the configured port and always connects on default port 6333

[strat97]

Bug Description

Repro steps

1. Add a Qdrant connection: host = qdrant.example.corp.lan, port = 443, SSL = on, API key set.
2. Save the connection and try to open it.
3. Connection fails with a generic TypeError: fetch failed. The extension host log shows only Connection: 'Qdrant' failed: TypeError: fetch failed.

Expected Behavior

Requests go to https://qdrant.example.corp.lan:443, the configured port is used.

Actual Behavior

Connection fails with a generic TypeError: fetch failed.

Environment

• DBCode version: 1.38.2
• VS Code (or fork) version: 1.136.2
• OS: macos
• Database: Qdrant
• Connection: https
• Server: Qdrant v1.19.1 (Helm chart), REST API exposed through an nginx ingress
  on port 443 (TLS, wildcard corporate certificate). Port 6333 is ClusterIP-only and
  is not reachable from the workstation.

Evidence

I temporarily instrumented the bundled client
(out/vendor/@qdrant/js-client-rest.js) in two places — the QdrantClient
constructor and globalThis.fetch — and reloaded the window. All of this happens
in the same extension host process (same PID):

CTOR url="https://qdrant.example.corp.lan:443" host=undefined port=6333 https=undefined prefix=undefined key=set
FETCHFAIL https://qdrant.example.corp.lan:6333/ cause=ECONNREFUSED
FETCHFAIL https://qdrant.example.corp.lan:6333/collections cause=ECONNREFUSED

The client is constructed with the correct URL (https://host:443, and the vendored
@qdrant/js-client-rest does parse the port from the URL correctly:
this._port = l.port ? Number(l.port) : 6333), yet the actual requests are issued
against the default port 6333 — the port configured in the connection settings
never reaches the code that performs the requests.

Wrapping globalThis.fetch and rewriting the port 6333 → 443 for the connection
host makes the connection work completely (collection browsing, introspection).
So the only defect is that the configured port is not propagated to the client
instance that actually issues requests — it falls back to the library's default
6333. (The scheme and API key are propagated correctly.)

[mikeburgh]

Fixed in 1.38.3 which has been released