fix(tests): stop the census guard reddening main on every legitimate conversion (#2856)

## This is the cause of four main reds today, not a fifth instance of
them

I have now fixed the census baseline on `main` three times (#2814, plus
a withdrawn branch, plus watching #2811 and #2844 do the same). Rather
than do it a fourth time, here is why it keeps happening.

`census-baseline-corruption-guard` asserted:

```ts
expect(result).toContain("every file matches its baseline exactly");
```

That demands the **committed baseline be byte-in-step with the tree at
all times**.

**It is not, by design.** A conversion PR that removes guards leaves the
tree holding *fewer* than the baseline allows, and the CLI treats that
as the good case — it tightens the pin and exits 0. Measured directly:

```
simulated drop → EXIT ON DROP: 0
  "The baseline file has been rewritten downward. COMMIT IT …
   in CI this write is discarded with the runner, which is why the gate is green and not silent."
```

So the ratchet was already happy while this test went red. Every
conversion that did not *also* re-record the baseline turned `main` red
for a condition that was never a defect.

That is the mechanism behind **#2783's markers, #2837's query split and
two more** — plus three collisions between workers racing to re-record
the same file (#2811/#2814, #2844, and a branch of mine I deleted rather
than open as a duplicate).

## The fix matches the guard's own stated intent

Its comment says: *"a guard that always fails is no guard"* — its job is
to prove the **corruption** diagnosis does not false-positive on a
healthy file. **A tightened baseline is healthy.** So it now asserts
what that needs:

- the run **succeeds** — `execFileSync` throws on a non-zero exit, so a
**rise still fails before any assertion runs**; a rise is real debt and
must stay loud
- the corruption diagnosis is **absent**
- the outcome is one of the two healthy shapes the CLI can report

## Measured discrimination — all four cases

| scenario | before | after |
|---|---|---|
| **drop** (legitimate conversion) | ❌ 1 failed — *the false red* | ✅ 3
passed |
| **rise** (real debt) | ❌ fails | ❌ **still fails** |
| **corrupt JSON** | ❌ fails | ❌ still fails (case unchanged) |
| **unreadable file** | ❌ fails | ❌ still fails (case unchanged) |

Only *"somebody converted guards and has not re-recorded the pin yet"*
stops being a red.

## Scope

Engine **11022 passed / 0 failed** · gate **732 green** · lint clean.
Test-only.

**Does not change** the CLI, the ratchet, or what `--strict` reports.
Re-recording the baseline on a drop is still the right thing to do — it
just stops being an emergency that reddens main and blocks everyone else
while three people race to fix it.

The baseline file is restored byte-clean after every simulation above
(`git diff` verified).

🤖 Generated with [Claude Code](https://claude.com/claude-code)

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

- **Tests**
- Expanded baseline validation coverage to detect unreadable or invalid
baseline data.
- Added support for both exact baseline matches and successfully
tightened baselines.
  - Improved health checks for baseline verification outcomes.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

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

packages/engine/src/__tests__/census-baseline-corruption-guard.test.ts

@@ -1,5 +1,5 @@
 /*
-FNXC:WorkflowLifecycleColumns 2026-07-31-15:10:
+FNXC:WorkflowLifecycleColumns 2026-07-30-16:35:
 
 THE INVARIANT: a corrupt census baseline fails with a DIAGNOSIS, and `--update-baseline` refuses to
 regenerate on top of one.
@@ -82,17 +82,39 @@ describe("the census fails readably on a corrupt baseline", () => {
   });
 
   it("still succeeds against the repo's real baseline", () => {
-    // Guards against the diagnosis firing on a healthy file — a guard that always fails is no guard.
+    /*
+    FNXC:LifecycleColumnCensus 2026-07-30-16:30:
+    ASSERTS A HEALTHY OUTCOME, NOT PERMANENT EXACT SYNC.
+
+    This required "every file matches its baseline exactly", which demands the COMMITTED baseline be
+    byte-in-step with the tree at all times. It is not: a conversion that removes guards leaves the
+    tree holding FEWER than the baseline allows, and the CLI treats that as the good case — it
+    tightens the pin and exits 0. So every legitimate conversion that did not also re-record turned
+    this test red on main (measured: four separate main reds in one day).
+
+    This guard's job is narrower — prove the CORRUPTION diagnosis does not fire on a healthy file —
+    and a tightened baseline IS healthy. It therefore asserts a zero exit (execFileSync throws
+    otherwise, so a RISE still fails: real debt stays loud), no corruption diagnosis, and one of the
+    two healthy outcome shapes.
+
+    A rise, a corrupt file, and an unreadable file all still fail. Only "converted guards, pin not
+    re-recorded yet" stops being red, which was never a defect.
+    */
     scratch = mkdtempSync(join(tmpdir(), "fusion-census-guard-"));
     const baselinePath = join(scratch, "baseline.json");
     copyFileSync(REAL_BASELINE, baselinePath);
 
+    /* Throws on a non-zero exit, so a RISE (exit 1) fails this test before any assertion runs. */
     const result = execFileSync("node", [SCRIPT, "--strict"], {
       cwd: REPO_ROOT,
       env: { ...process.env, FUSION_CENSUS_BASELINE_PATH: baselinePath },
       encoding: "utf8",
     });
 
-    expect(result).toContain("every file matches its baseline exactly");
+    expect(result).not.toContain("is not valid JSON");
+    expect(result).not.toContain("could not be read");
+    const healthy = result.includes("every file matches its baseline exactly")
+      || result.includes("baseline TIGHTENED");
+    expect(healthy, `census reported neither healthy outcome:\n${result}`).toBe(true);
   });
 });