Merge branch 'main' into feature/techlog-ui-migration

Integrates the frontend template sync (a0fbafb → 5434760) into the TechLog UI
migration. Merged in this direction so every conflict is resolved and proved in
the worktree; main is only fast-forwarded afterwards and never holds a state
that was not verified here.

15 conflicts. The rule throughout: keep the template's mechanism, keep the
product's content, and never invent a third state neither branch would accept.

The template's product manifest and its runtime feature kill switch are adopted.
The route registry is deliberately not composed from contract.routes: the
reference feature still declares screens this product deleted, and reducing over
them would register paths with no component behind them. ROUTE_FEATURE_OWNER is
narrowed to registered routes for the same reason. The first resolution did
compose from contract.routes and was rejected by product-features.test.ts.

Three files pinned counts and a digest describing the gate contract. Neither
side's numbers describe the merged config/ci/gates.json, so they were recomputed
from it rather than chosen: 27 gates, 82 commands, 94 command references, 107
evidence references, 128 artifacts, shape sha256 5063586d.

README.md and docs/accessibility/manual-checklist.md now enumerate this
product's 27 routes, which the template's own verify:documentation requires.

product-feature-switch.test.tsx was rewritten around the invariant that still
applies here — no registered route without a component — rather than deleted
with the screens it used to exercise.

docs/operations/template-merge-2026-08-17.md records every decision, the gate
results, and the three follow-ups this merge deliberately did not decide.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

vite.config.ts

@@ -43,7 +43,28 @@ function routeChunkName(moduleId: string): string | undefined {
   return techLogRouteChunks[routePath as keyof typeof techLogRouteChunks];
 }
 
+/**
+ * §6.1. One sub-path, declared once.
+ *
+ * `VITE_ROUTER_BASE_PATH` already drives the router and the Service Worker
+ * scope. Vite's asset `base` was left at its default, so a build served from
+ * `/app/` emitted root-absolute asset URLs and loaded nothing: the three
+ * consumers of the same setting disagreed. They are read from one value here so
+ * a sub-path deployment is coherent or fails at build time.
+ */
+function routerBasePath(environment: NodeJS.ProcessEnv): string {
+  const declared = environment["VITE_ROUTER_BASE_PATH"];
+  if (declared === undefined || declared === "") return "/";
+  if (!declared.startsWith("/") || !declared.endsWith("/")) {
+    throw new Error(
+      `VITE_ROUTER_BASE_PATH must start and end with "/"; received ${declared}`,
+    );
+  }
+  return declared;
+}
+
 export default defineConfig({
+  base: routerBasePath(process.env),
   plugins: [react(), tailwindcss(), viteModuleInventoryPlugin()],
   build: {
     manifest: true,