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>

tests/component/product-feature-switch.test.tsx

@@ -0,0 +1,47 @@
+import { describe, expect, it } from "vitest";
+
+import {
+  ROUTE_FEATURE_OWNER,
+  ROUTE_REGISTRY,
+} from "../../src/features/installed-feature-contracts.ts";
+import { ROUTE_RUNTIME } from "../../src/features/installed-feature-runtimes.tsx";
+import { INSTALLED_PRODUCT_FEATURE_IDS } from "../../src/features/installed-product-manifest.ts";
+
+/**
+ * §3.5. The runtime kill switch, as it applies to *this* product.
+ *
+ * The template asserted the switch end to end by rendering the reference
+ * feature's screens and taking them out of service. This product deleted those
+ * screens during the UI migration, so that render is no longer possible: the
+ * feature contributes API operations, schemas and mappers, but no route.
+ *
+ * Deleting the test with the screens would have removed the only thing watching
+ * this seam, so what is asserted here is the invariant that survives the
+ * migration and would have caught the trap the merge itself nearly introduced —
+ * a route registered from a feature contract whose component no longer exists.
+ * The moment a feature-owned route is registered again, the second test starts
+ * asserting the switch end to end without being rewritten.
+ */
+describe("runtime product feature switch", () => {
+  it("registers no route that cannot be mounted", () => {
+    const unmountable = Object.keys(ROUTE_REGISTRY).filter(
+      (routeId) => !(routeId in ROUTE_RUNTIME),
+    );
+    expect(unmountable).toEqual([]);
+  });
+
+  it("keeps every feature-owned route inside the installed selection", () => {
+    // A route owned by a feature the manifest did not install would be
+    // reachable with nothing behind it.
+    const orphaned = Object.entries(ROUTE_FEATURE_OWNER)
+      .filter(([routeId]) => routeId in ROUTE_REGISTRY)
+      .filter(([, featureId]) => !INSTALLED_PRODUCT_FEATURE_IDS.includes(featureId));
+    expect(orphaned).toEqual([]);
+  });
+
+  it("still declares a product manifest to narrow", () => {
+    // The switch is only meaningful while something is selectable; if this ever
+    // empties, the mechanism above is dead code rather than a guarantee.
+    expect(INSTALLED_PRODUCT_FEATURE_IDS.length).toBeGreaterThan(0);
+  });
+});