Record that a sub-path server URL is silently dropped

Found while sweeping for the stale default. The client uses the typed address
only as HttpClient.BaseAddress and every request path is root-absolute, so
https://example.test/dodossh reaches https://example.test/api/v1/... with the
prefix discarded and no error — which rules out hosting under a sub-path, the
usual arrangement behind a proxy fronting several services. The server
already publishes a canonical apiBaseUrl the client could normalise against
and ignores.

Recorded rather than fixed: it is a deployment-shape decision, not a bug in
the screen that prompted this.

docs/platform-flags.md

@@ -270,6 +270,15 @@ publish when resolving `localhost` — so every realm request returned 404 while
 looked healthy. If discovery fails against a locally-published container, check for another
 process bound specifically to loopback before suspecting the container.
 
+**A path prefix in the server URL is silently discarded.** The client uses the typed address only as
+`HttpClient.BaseAddress` and every request path is root-absolute (`/api/v1/meta`,
+`/.well-known/dodossh-configuration`, …), so `https://example.test/dodossh` reaches
+`https://example.test/api/v1/...` and the prefix is dropped without a word. That rules out hosting DodoSSH
+under a sub-path — which is exactly what a reverse proxy in front of several services usually does. Nothing
+trims or normalises the typed URL either, and it is the raw string, not the parsed form, that becomes the
+local cache's identity. The server already publishes a canonical `apiBaseUrl` in its discovery document
+that the client could normalise against and currently ignores.
+
 **`Sync:CursorSigningKey` generates an ephemeral per-process key when unset.** Fine for a single
 node; on a multi-node deployment cursors issued by one node are rejected by another, so clients
 resync from the beginning repeatedly. Must be configured explicitly before running more than one