feat(showcase): add shell-dojo runtime-config server+client

Mirror of the runtime-config pattern from shell-dashboard for shell-dojo
(B7). shell-dojo has no URL consumers today (B0 audit reported zero
process.env.NEXT_PUBLIC_* reads), so RuntimeConfig is an empty object
literal. Module exists to keep the runtime-config / layout-injection
pattern symmetric across all four shells; adding a URL later is a
single field addition.

- src/lib/runtime-config.ts: server reader with unstable_noStore()
  opt-out (Node) and noStore-skip option (Edge wrapper not needed yet).
- src/lib/runtime-config.client.ts: client reader from
  window.__SHOWCASE_CONFIG__ injected by root layout.

No tests included for shell-dojo: matches B7 file list (no test files
listed for shell-dojo) and reflects that there is no behavior to assert
on an empty config beyond the type contract.

Author: jpr5

showcase/shell-dojo/src/lib/runtime-config.client.ts

@@ -0,0 +1,52 @@
+// Client-side runtime config reader. Reads from
+// window.__SHOWCASE_CONFIG__ which the root layout injects via an
+// inline <script> tag BEFORE React hydrates (see app/layout.tsx). This
+// is the ONLY public API for these URLs in client code — never read
+// process.env.NEXT_PUBLIC_* directly (the ESLint rule in B12 enforces
+// this).
+//
+// shell-dojo's `RuntimeConfig` is intentionally empty today (no URL
+// consumers); the module exists to keep the pattern symmetric across
+// shells. When a URL is added on the server side, this reader picks it
+// up via the shared interface.
+
+import type { RuntimeConfig } from "./runtime-config";
+
+export type { RuntimeConfig };
+
+declare global {
+    interface Window {
+        __SHOWCASE_CONFIG__?: RuntimeConfig;
+    }
+}
+
+/**
+ * Returns the runtime config injected by the root server layout.
+ *
+ * Throws when called during SSR (no window). The intended call sites
+ * are client components and hooks ("use client"), which only execute
+ * after hydration — by which point the inline <script> has populated
+ * window.__SHOWCASE_CONFIG__. If a server component needs the same
+ * values, it MUST import runtime-config.ts (the server variant) — not
+ * this file.
+ */
+export function getRuntimeConfig(): RuntimeConfig {
+    if (typeof window === "undefined") {
+        throw new Error(
+            "[runtime-config.client] getRuntimeConfig() called on the server. " +
+                "Server code must import from './runtime-config' instead.",
+        );
+    }
+    const cfg = window.__SHOWCASE_CONFIG__;
+    if (!cfg) {
+        // The root layout always emits the <script> tag, so a missing
+        // value here is a wiring bug (e.g. a route bypassed the layout,
+        // or the injection script ran with empty inputs). Surface it
+        // loudly rather than silently returning empty strings.
+        throw new Error(
+            "[runtime-config.client] window.__SHOWCASE_CONFIG__ is missing. " +
+                "The root layout must inject runtime config before client mount.",
+        );
+    }
+    return cfg;
+}

showcase/shell-dojo/src/lib/runtime-config.ts

@@ -0,0 +1,46 @@
+// Server-only runtime config reader. Reads from process.env at REQUEST
+// time (not at module load) so a single built artifact can serve
+// different URL values across staging vs prod by changing the Railway
+// service's env vars — no rebuild required.
+//
+// `unstable_noStore()` opts the calling segment out of Next.js's static
+// cache so reads always reflect the live env. Without it, a server
+// component that uses this could be statically rendered at build time
+// and freeze the URLs back into the artifact (the exact bug we are
+// fixing). See Next.js App Router docs on Dynamic Rendering.
+//
+// This module MUST NOT be imported from client components. The matching
+// client-side reader lives in runtime-config.client.ts and reads from
+// window.__SHOWCASE_CONFIG__ which the root layout injects.
+//
+// shell-dojo today has no URL consumers (audit B0 reported zero
+// process.env.NEXT_PUBLIC_* reads). The `RuntimeConfig` interface is
+// intentionally an empty object literal — it exists to keep the
+// runtime-config / layout-injection pattern symmetric across all four
+// shells. Adding a URL later means adding a field here, reading it
+// from process.env via `readUrl`, and the client-side reader picks it
+// up automatically through the shared interface.
+
+import { unstable_noStore as noStore } from "next/cache";
+
+// eslint-disable-next-line @typescript-eslint/no-empty-object-type
+export interface RuntimeConfig {}
+
+/**
+ * Resolve the runtime config for shell-dojo. Called once per request
+ * by the root layout. Currently returns an empty object since
+ * shell-dojo has no URL-dependent consumers; the module exists to keep
+ * the pattern symmetric across shells (see shell-dashboard's
+ * runtime-config.ts for the full template).
+ *
+ * `opts.noStore` (default `true`) controls whether to call
+ * `unstable_noStore()`. The Node.js server runtime needs the opt-out
+ * so Next.js does not statically prerender callers and freeze any
+ * future URL values into the build artifact.
+ */
+export function getRuntimeConfig(
+    opts: { noStore?: boolean } = {},
+): RuntimeConfig {
+    if (opts.noStore !== false) noStore();
+    return {};
+}