fix(rest): /discovery no longer contradicts itself — services.*.route follows the mounted paths (#17399)

* fix(rest): mirror the mounted paths onto discovery's `services.*.route`

`/discovery` states each service address twice — `routes.X` and
`services.Y.route` — and the REST discovery handler rewrote only the first
half to the paths this server mounts. A deployment that moved a prefix got a
document that contradicted itself, with the `services` half addressing a path
nothing is mounted on.

The `services` half is now written as a projection of the finished `routes`
map, key by key, so the two cannot state different answers whatever a future
substitution does to `routes`. Three guards keep a default deployment
byte-identical: only a slot the producer emitted, only one that already
declares a route, and only from a route key that survived the pass.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DapQyvYrFb1MxSYe7BL2nt

* test(rest): reduce the #9292 per-request pin past the mount projection

`discovery-per-request-protocol.test.ts` compares the served document's
`services` map against the raw `getDiscovery()` of the environment's own
protocol, to prove `/discovery` follows the REQUEST's kernel. Mirroring the
mounted paths onto `services.*.route` adds a handler overlay to that value:
on a scoped request `services.data.route` now reads
`/api/v1/environments/tenant-a/data`, which the producer — who cannot see a
mount — will never say.

`substance()` already reduces `capabilities` to its `enabled` bits for exactly
this reason ("those overlays are a different contract with its own pins"). The
same reduction now applies to the route VALUE, keeping the kernel-determined
fact the pin is about: whether the slot advertises an address at all. The
overlay itself is pinned next door in
`discovery-services-route-follows-mount.test.ts`, against `routes.X` in the
same served document.

⛔ Nothing is skipped, disabled or quarantined: all four `toEqual` /
`not.toEqual` halves still run, and the negative halves still separate the
three protocols.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DapQyvYrFb1MxSYe7BL2nt

---------

Co-authored-by: Claude <noreply@anthropic.com>

Author: os-justin

.changeset/discovery-services-route-follows-mount.md

@@ -0,0 +1,18 @@
+---
+"@objectstack/rest": patch
+---
+
+fix(rest): `/discovery` no longer contradicts itself — `services.*.route` follows the mounted paths, like `routes.*` already did (#16674)
+
+The `/discovery` document states each service's address twice: once in `routes.X` (the flat convenience map) and once in `services.Y.route` (the per-slot entry). The REST discovery handler rewrote only the first half to the paths this server actually mounts, so any deployment that moved a prefix received a document that disagreed with itself — and the `services` half pointed at a path with nothing mounted on it.
+
+Measured on a boot with `crud: { dataPrefix: '/objects' }`, reading `GET /api/v1/discovery`:
+
+- before — `routes.data` = `/api/v1/objects` (the mounted path), `services.data.route` = `/api/v1/data` (unmounted)
+- after — both answer `/api/v1/objects`
+
+The same split opened on four keys at once for an `apiPath` deployment: `data`, `metadata`, `ui` and `auth`. All four now follow the mount. `services.*.route` is written as a projection of the finished `routes` map, so the two halves cannot state different answers whatever a future substitution does to `routes`.
+
+**A default deployment's document does not move by a byte.** With `crud.dataPrefix` at its `/data` default and `metadata.prefix` at `/meta`, the values the correction writes are the values that were already there; only a deployment that had moved a prefix sees a change, and there the old value addressed nothing. Route-less slots (`cache`, `queue`, `job`, and an in-process `realtime` bus) never gain a route, and no advertisement is withdrawn.
+
+If you have been reading `services.data.route` on a moved-prefix deployment and compensating for it — by re-deriving the path from `routes.data`, or by hard-coding the prefix — that workaround can go: the field now answers the mounted path directly.

packages/rest/src/discovery-per-request-protocol.test.ts

@@ -119,14 +119,33 @@ const API_CONFIG = {
  * make this file assert them too, and fail the day either description is
  * reworded. The `enabled` bit is what the environment's own kernel decides,
  * and it is what a client reads.
+ *
+ * [#16674] `services.*.route` is reduced the same way, and for the same
+ * reason: since the substitution pass mirrors the mounted paths onto the
+ * `services` half, that VALUE is a handler overlay carrying THIS SERVER's base
+ * — on a scoped request `services.data.route` reads
+ * `/api/v1/environments/tenant-a/data`, which the producer, who cannot see a
+ * mount, will never say. Comparing it here would assert the mount projection
+ * rather than the kernel's answer, and it has its own pins next door
+ * (`discovery-services-route-follows-mount.test.ts`, which asserts it equals
+ * `routes.X` in the served document). What this file still asserts is the part
+ * the environment's own kernel decides: WHETHER the slot advertises an address
+ * at all — a fact the mirror never changes, since it neither invents a route
+ * on a route-less slot nor withdraws one.
  */
 function substance(doc: any) {
   return {
     capabilities: Object.fromEntries(
       Object.entries(doc.capabilities as Record<string, { enabled: boolean }>)
         .map(([k, v]) => [k, v.enabled]),
     ),
-    services: doc.services,
+    services: Object.fromEntries(
+      Object.entries(doc.services as Record<string, Record<string, unknown>>)
+        .map(([slot, info]) => {
+          const { route, ...kernelDetermined } = info;
+          return [slot, { ...kernelDetermined, advertisesRoute: typeof route === 'string' }];
+        }),
+    ),
     locale: doc.locale,
   };
 }