fix(t27-worlds): the nightly scan writes the onboarding counts it measured

[dmitrii-f-t27]

What

The nightly t27 world scan stopped at Catalog gates on 2026-10-02 (run 36992363784):

onboarding-from-spec: 6 problem(s)
  specs/catalog/onboarding.t27: SPEC_COUNT says 1737, the manifest says 1771 -- write 1771
  ... SPEC_LINES, HEALTH_OK, HEALTH_WARN, HEALTH_FAIL, HEALTH_PARTIAL

check:onboarding was added to the scan after #1176 so that a refresh cannot publish counts that disagree with the manifest, which is right. But the corpus moves almost every night, and nothing in the scan wrote the new counts, so every refresh that moved them stopped. While it is stopped the Queen atlas does not change either: dmitrii-f-t27/trinity-memory still shows three red issue cells for #103, #105 and #107, which were closed as completed on 2026-10-01, half an hour after the snapshot was taken.

Change

• onboarding-from-spec.mjs --sync writes into the spec exactly the values corpusProblems asks for, taken from the manifest that is about to be published. Both read them from the new measuredCounts and divergentSpecs, so the value the gate expects and the value the sync writes cannot drift apart. It dates them in MEASURED_AT, then regenerates /agents.t27 and /llms.txt.
• It refuses a value its declared type cannot hold (u8/u16/u32) and never touches BACKENDS, so the gate still stops a refresh for those.
• t27-world-scan.yml runs --sync after the atlas build and before the gates, and commits specs/catalog/onboarding.t27, public/agents.t27 and public/llms.txt with the rest of the catalog.
• scripts/onboarding-from-spec.test.mjs (4 tests) runs in Website checks next to check:onboarding.

Checks

• npm run test:onboarding-spec: 4 pass. Negative control: with the write removed from syncSpecCounts, the grown-corpus test fails.
• npm run check:onboarding: the committed spec and manifest still agree (no count changes in this PR).

Work report

{
  "version": 1,
  "head_sha": "5b1715b4cd3f7e576ab8c98c4174cdc78a53ef84",
  "summary": "The nightly t27 world scan stopped refreshing the catalog on 2026-10-02 because check:onboarding found the onboarding spec stating 1737 specs while the freshly built manifest measured 1771, and nothing in the scan wrote the new counts. The scan now writes the measured counts into specs/catalog/onboarding.t27 with a new --sync mode before its gates, so the catalog, the Queen atlas and its issue cells refresh again while the gate keeps refusing what the sync does not own.",
  "changes": [
    "onboarding-from-spec.mjs: measuredCounts and divergentSpecs are extracted so the gate and the sync read the same measured values from the manifest.",
    "onboarding-from-spec.mjs: --sync writes those counts into the spec constants, dates them with MEASURED_AT, refuses a value its declared unsigned type cannot hold, and then regenerates agents.t27 and llms.txt.",
    "t27-world-scan.yml: the scan step runs the sync after the atlas build, the gate comment says what can still stop a refresh, and the catalog commit now includes the spec and the two generated files.",
    "onboarding-from-spec.test.mjs: four node tests cover an unchanged manifest, a grown corpus, a u8 overflow and a new backend; website-checks.yml runs them next to check:onboarding."
  ],
  "tests": [
    {
      "command": "npm run test:onboarding-spec",
      "result": "four tests pass on the committed spec and manifest",
      "status": "passed",
      "evidence": "node test runner reported pass 4 and fail 0"
    },
    {
      "command": "npm run check:onboarding",
      "result": "the committed spec still agrees with the committed manifest and the generated files are current",
      "status": "passed",
      "evidence": "onboarding-from-spec reported up to date with all ten spec tests holding"
    },
    {
      "command": "node --test with the write line removed from syncSpecCounts",
      "result": "the grown-corpus test fails as intended, so the test detects a sync that writes nothing",
      "status": "passed",
      "evidence": "negative control run reported pass 3 and fail 1 on that one test"
    },
    {
      "command": "t27 world scan workflow on main after merge",
      "result": "the next scheduled run is the end to end check of the new step and has not happened yet",
      "status": "not_run",
      "evidence": "the 2026-10-02 run 36992363784 failed at Catalog gates before this change"
    }
  ],
  "limitations": [
    "BACKENDS is still written by hand on purpose, so a new code generator will stop the scan until someone names it in the spec.",
    "MEASURED_AT takes the date of the scan run because the manifest carries no timestamp of its own.",
    "The Queen site at app.t27.ai serves the atlas pinned by QUEEN_REF, so a refreshed catalog reaches it only with the next release."
  ],
  "tags": [
    "#ci",
    "#catalog",
    "#queen"
  ],
  "blog": {
    "title": "The nightly catalog scan stopped on a number it was not allowed to write",
    "summary": "A safety gate compared the published onboarding counts with the freshly measured manifest and stopped the nightly refresh whenever the corpus grew, which was almost every night, so the map kept showing work that had already been closed.",
    "outline": [
      "The t27 world scan rebuilds the catalog manifest every night from fourteen repositories, and the Queen map draws its worlds, specs and open issues from that snapshot.",
      "After an earlier refresh broke publishing, a gate was added that compares the counts stated in the onboarding spec with the manifest and stops the scan when they differ.",
      "The corpus grows almost every night, and nothing in the scan wrote the new counts, so the gate stopped the refresh and three issues closed on 2026-10-01 stayed red on the map.",
      "The fix gives the generator a sync mode that writes the measured counts into the spec before the gate runs, using the same function the gate uses to compute what it expects.",
      "The gate is still there for what the sync does not own, such as a new backend name or a count that no longer fits its declared type, and four tests hold that boundary."
    ]
  }
}

Dmitrii Fedorov (@dmitrii-f-t27)