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>

src/presentation/routes/app-router.tsx

@@ -17,7 +17,10 @@ import {
   useSearchParams,
 } from "react-router-dom";
 
-import { ROUTE_REGISTRY } from "../../features/installed-feature-contracts.ts";
+import {
+  ROUTE_FEATURE_OWNER,
+  ROUTE_REGISTRY,
+} from "../../features/installed-feature-contracts.ts";
 import type {
   RouteDefinition,
   RouteLayoutGroup,
@@ -104,6 +107,26 @@ function InvalidRouteSurface({ code }: { code: string }) {
   );
 }
 
+/**
+ * §3.5. A route whose feature the runtime document switched off. It answers as
+ * "not available" rather than rendering the feature or crashing, so disabling a
+ * feature is a deployment action and not an outage.
+ */
+function DisabledFeatureSurface({ featureId }: { featureId: string }) {
+  const { message } = useLocale();
+  return (
+    <section className="ui-page" data-surface="disabled-feature">
+      <PageHeader
+        title={message("route.disabledFeature.title")}
+        description={message("route.disabledFeature.description")}
+      />
+      <p data-disabled-feature={featureId}>
+        {message("route.disabledFeature.action")}
+      </p>
+    </section>
+  );
+}
+
 function RouteLifecycle({
   definition,
   buildId,
@@ -269,7 +292,17 @@ function RegisteredRoute<RouteIdValue extends string>({
   const params = useParams();
   const [search] = useSearchParams();
   const location = useLocation();
-  const { diagnostics, recovery } = useApplication();
+  const { diagnostics, runtime: platformRuntime, recovery } = useApplication();
+  // §3.5 (template merge). A feature the runtime document disabled is out of
+  // service, not merely hidden: withdrawing it from navigation alone would
+  // leave a typed deep link that still mounts it. The template looked the
+  // definition and the runtime component up by id here; on this branch both
+  // arrive as props from the grouped route contract, so only the kill switch
+  // is adopted.
+  const owner = ROUTE_FEATURE_OWNER[routeId];
+  if (owner !== undefined && !platformRuntime.isFeatureActive(owner)) {
+    return <DisabledFeatureSurface featureId={owner} />;
+  }
   const parsed = parseRouteInputFromContract(
     routeId,
     definition,