docs: state when contract-set verification actually fails the dev boot

The README framed a missing `contractSet` package as a caveat of switching to
`HTTP`. It is not conditional on `TECH_LOG_STUDIO_SOURCE` at all —
`public/config.json` never set that key, and `pnpm dev` still failed to boot in
the default `MOCK` mode. Filing a total dev-server outage under an opt-in
switch is what let it sit unnoticed.

Says plainly that verification runs unconditionally at boot, which half can
drift, and what keeps the two in sync. Drops the "graceful, non-blank error
screen" reassurance for the default path: a developer running `pnpm dev` and
getting a boot error has a broken dev server whatever the screen looks like.

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

README.md

@@ -78,13 +78,36 @@ The switch is a field on the versioned runtime config document
   `public/config.json` (and `public/release-manifest.json`) verbatim as dev
   fixtures — editing `config/runtime/local.json` alone has no effect on
   `pnpm dev`. To exercise `HTTP` mode under `pnpm dev`, set
-  `TECH_LOG_STUDIO_SOURCE` in `public/config.json` directly. Switching to
-  `HTTP` also requires `public/release-manifest.json`'s `contractSet` to
-  declare the `@tech-log/studio-contract` package the build compiled in
-  (`.generated/frontend-runtime/contract-set.ts` after a build), or boot fails
-  closed earlier, at contract-set verification (`CONTRACT_SET_PACKAGE_MISSING`)
-  — itself a graceful, non-blank error screen, just not the one this switch is
-  usually used to exercise.
+  `TECH_LOG_STUDIO_SOURCE` in `public/config.json` directly.
+
+### The dev release manifest must declare the compiled contract set
+
+Contract-set verification runs unconditionally at boot, before any adapter is
+selected. It is not an `HTTP`-mode caveat: if `public/release-manifest.json`'s
+`contractSet` does not match the set the build compiled, `corepack pnpm dev`
+does not start the app at all — it renders the fail-closed boot screen
+(`CONTRACT_SET_MISMATCH` / `CONTRACT_SET_PACKAGE_MISSING`) in the **default
+`MOCK` mode** too. A developer who runs `pnpm dev` and gets a boot error has a
+broken dev server, however tidy the screen looks; treat it as a defect in the
+fixture, never as expected behaviour.
+
+The expectation comes from `EXPECTED_CONTRACT_SET_PACKAGES`
+(`src/features/installed-contract-contributions.ts`), and a real build writes it
+into `dist/release-manifest.json` from `scripts/generate-contract-set.ts`, so
+production builds are always self-consistent. Only the hand-maintained dev
+fixture can drift, and it drifts whenever either half moves — a regenerated
+contract (new package digest or version) or a contribution added to or removed
+from `installed-contract-contributions.ts`. Two things keep it honest:
+
+- `corepack pnpm generate:tech-log-contract` refreshes the fixture's
+  `contractSet` block as its last step, so regenerating the contract can never
+  leave the two out of step. `corepack pnpm generate:dev-release-manifest`
+  refreshes the same block on its own, for the contribution-list case that does
+  not go through contract generation.
+- `corepack pnpm check:dev-release-manifest` is the gate. It compares the
+  fixture's `setAlgorithm`, `setDigest` and package set against the compiled
+  set and fails on any difference. It runs in CI as part of FE-GATE-010, which
+  is what catches the changes the generation step cannot see.
 
 ### TechLog contract generation