Add the operator console's live telemetry socket

The only socket until now was the gateway-facing /ws/edge/v1, which
authenticates as a *farm* with a credential any of its gateways holds,
and which accepts telemetry. Pointing a browser at it would mean handing
the browser something that can drive printers. /ws/telemetry
authenticates as a *user* with a Supabase access token, and accepts
nothing at all: it is push-only, and a frame arriving from the browser is
ignored. Everything that changes a printer keeps going over HTTP, where
the role checks and the audit trail already are.

Auth is checked at the upgrade, as on the edge socket, so an
unauthenticated browser never gets a socket. The token rides in
`Sec-WebSocket-Protocol` - `new WebSocket(url, ["bearer", token])` -
because that field is the whole of what JavaScript controls about a
browser handshake, and the usual workaround of `?token=` would put a
bearer credential into every access and proxy log. "bearer" is first
because the runtime echoes the *first* offered value back in the
response header, so the token must not be in that position; asserted,
not assumed.

The payload is the printer resource itself, returned straight out of
`persistTelemetry`'s UPDATE through `printerProjection` - the same
projection the REST routes use. So a push is byte-for-byte what
`GET /printers/:id` would have answered, and a client applies it to the
row it already holds. Rebuilding it from the gateway's snapshot instead
would be a second translation of the same data, free to drift, and
missing the columns a gateway never reports at all like `name` and
`vendor`.

`maySee` is what keeps one organisation's telemetry out of another's
console, and it lives in `telemetry/broadcast.ts` with no imports but a
type so it can be tested without a socket or a database - the same reason
as `dispatch/job_status.ts`, `stream.ts` and `auth/edge_upgrade.ts`. It
refuses a printer with no farm rather than matching it against anything,
which no row can be today, because this is the one function where being
wrong leaks another org's machines.

**A latent bug this turned up:** the edge route's resolve was
`{ as: "scoped" }`, copied from `requireUser`. For `requireUser` that is
right - it is used inside each route file and must propagate `user` to
that file's routes. On a ws plugin it propagates the check to the parent
app, where it gates every route mounted *after* that plugin. Measured
with a two-plugin probe: the second plugin's own socket is refused
because the first one's check runs first and finds no edge token. Nothing
shipped broken only because /ws/telemetry is the first route mounted
after it - and it was refused outright until this was found. Both ws
resolves now use the default `local` scope.

Known limits, both written down rather than discovered later:

- **In-process fan-out.** A `Set` of callbacks in one process, so two
  backend instances would each push only the telemetry their own
  gateways are connected to and an operator would see half a fleet. The
  fix is Valkey pub/sub, already a dependency; doing it now would mean
  testing a message broker to deliver events between two objects in the
  same process.
- **Visibility is resolved once, when the socket opens.** Re-deriving it
  per message would put a database round trip on every push to every
  viewer. The direction that matters: someone removed from an
  organisation keeps receiving its telemetry until their socket drops.
  Closing that needs a signal on membership change that this backend does
  not have; a periodic re-resolve would narrow the window without closing
  it. Telemetry is also the least sensitive thing here, and every HTTP
  route re-checks on each request.

Verified against the real stack, not just mirrored in unit tests:
`scripts/e2e-edge.sh` now drives the actual route with a real
JWKS-verified token and asserts the handshake echoes "bearer", that a
`ready` frame arrives, and that a real push carries the printer resource
with live readings - "2 push(es); last was H2C state=FINISH nozzle=30
camera=h2c". A bogus token is refused before any socket exists.
`scripts/watch-telemetry.ts` is the client it uses, and is the quickest
way to see by hand whether a farm's telemetry reaches a console.

110 tests (was 95), `bunx tsc --noEmit` clean.

src/auth/ws_subprotocol.ts

@@ -0,0 +1,50 @@
+import { UnauthorizedError } from "@continuum/ts-core";
+
+/**
+ * Pulls a bearer token out of a WebSocket's `Sec-WebSocket-Protocol` header.
+ *
+ * A leaf module with no imports but the error type, like
+ * `auth/edge_upgrade.ts` next to it, and for the same reason: this is an
+ * authentication boundary and should not need a database to test.
+ *
+ * ## Why the subprotocol and not a query parameter
+ *
+ * A browser cannot set headers on a WebSocket - `new WebSocket(url, protos)`
+ * is the whole of what JavaScript controls about the handshake. So the usual
+ * `Authorization: Bearer` is unavailable, and the common workaround is
+ * `?token=...`, which puts a bearer credential in a URL and therefore into
+ * access logs, proxy logs and error breadcrumbs. This codebase already goes
+ * out of its way to avoid that: continuum-proxy hand-writes a `Debug` so a
+ * presigned URL prints as `<redacted>`.
+ *
+ * The subprotocol field is a header, is not logged by default, and - unlike
+ * a message-based handshake - is available *before* the upgrade, so an
+ * unauthenticated peer never gets a socket at all. The gateway socket gets
+ * the same property through a real `Authorization` header, which it can use
+ * because it is not a browser.
+ *
+ * The client sends `["bearer", "<token>"]`. "bearer" goes first because the
+ * server must echo exactly one offered value back or the browser fails the
+ * connection, and the runtime echoes the first - so the token itself must
+ * not be in that position, or it would come back in the response header.
+ */
+const SCHEME = "bearer";
+
+export function tokenFromSubprotocol(header: string | null | undefined): string {
+  const offered = (header ?? "")
+    .split(",")
+    .map((part) => part.trim())
+    .filter((part) => part.length > 0);
+
+  // Exactly two: the scheme and the token. Being strict here rather than
+  // scanning for "the entry that looks like a JWT" means a client that gets
+  // the order or the count wrong is told so, instead of working by accident
+  // until the day something else is in the list.
+  if (offered.length !== 2 || offered[0] !== SCHEME) {
+    throw new UnauthorizedError(
+      `WebSocket subprotocol must be ["${SCHEME}", "<access token>"]`,
+    );
+  }
+
+  return offered[1]!;
+}