test(engine): drop four redundant sync-reader stubs — they fed the broken reader the right answer (#3198)

Completes the audit filed as #3197.

## Why a stub here is not neutral

`resolveTaskWorkflowIrSync` answers with the **default board for every
task** in production — its selection reader returns `undefined`
unconditionally under PostgreSQL. A test that stubs it with a working IR
proves its call site's *logic* while being structurally unable to notice
that the real path resolves nothing. The suite stays green even if the
site goes inert, which is the failure this whole phase has been chasing.

## The audit, complete

Deleted each stub and checked whether the suite still discriminates:

| file | without the stub | verdict |
|---|---|---|
| `planner-lane-resolution` | 7 passed | redundant → **removed** |
| `triage-undeclared-column-rescue` | 7 passed | redundant → **removed**
|
| `recover-approved-intake-post-u11` | 6 passed | redundant →
**removed** |
| `workflow-scheduler-parked-columns-live-e2e.pg` | 2 passed | redundant
→ **removed** |
| `planner-lanes-async-resolution` | 1 failed | **legitimate** — the
stub is its subject |
| `scheduler-renamed-hold-events` | **3 failed** | **masking** — see
#3082 |
| `triage.test.ts`, `triage-release-renamed-hold` | — | resolved in
#3191 / #3193 / #3195 |

**Only the redundant four are touched.**

`planner-lanes-async-resolution` stubs the reader *deliberately*, to
contrast the two resolvers given the same store and task — removing it
would delete the point of the file. That is the case that makes this a
hand audit rather than a ratchet: a hit is not presumptively a defect.

`scheduler-renamed-hold-events` is left alone because its three failures
**are the finding, not the fix**. They correspond to the 13 inert guards
`check-inert-sync-lanes` counts in `scheduler.ts` — two independent
instruments agreeing that those handlers are green in tests and dead in
production on renamed boards. They live in synchronous `task:*`
listeners, so they need the emitter-side work in #3082, not a stub edit.

## Verification

- 4 files / **22 tests pass** without the stubs
- engine `tsc` 0 errors
- `census --strict`, `check-inert-sync-lanes`,
`check-fnxc-future-dates`: exit 0

The PG e2e was the one file I had marked unaudited when filing #3197; it
ran here and is included rather than left as an open question.

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

packages/engine/src/__tests__/planner-lane-resolution.test.ts

@@ -26,7 +26,14 @@ function storeWith(ir: WorkflowIr | null): TaskStore {
     getTaskWorkflowSelection: vi.fn(() => selection),
     getTaskWorkflowSelectionAsync: vi.fn(async () => selection),
     getWorkflowDefinition: vi.fn(async () => (ir ? { ir } : null)),
-    resolveTaskWorkflowIrSync: vi.fn(() => { if (!ir) throw new Error("no ir"); return ir; }),
+    /*
+    FNXC:WorkflowResolvedColumns 2026-07-31-23:59:
+    The `resolveTaskWorkflowIrSync` stub is REMOVED, and it was redundant: this suite passes without
+    it. That reader answers with the DEFAULT board for every task in production, so stubbing it with a
+    working IR feeds the broken reader the right answer — the suite would keep passing even if its
+    call site stopped resolving. Audited across the 8 files that stubbed it (#3197): four were
+    redundant like this one, one is legitimately about the sync path, one was masking real inertness.
+    */
   } as unknown as TaskStore;
 }
 

packages/engine/src/__tests__/recover-approved-intake-post-u11.test.ts

@@ -99,7 +99,14 @@ function createStore(task: Task, workflowIr: WorkflowIr): TaskStore {
     silently takes the legacy `{ intake: "triage" }` fallback, which reads as "the
     conversion does not work" rather than "the fake is incomplete".
     */
-    resolveTaskWorkflowIrSync: vi.fn(() => workflowIr),
+    /*
+    FNXC:WorkflowResolvedColumns 2026-07-31-23:59:
+    The `resolveTaskWorkflowIrSync` stub is REMOVED, and it was redundant: this suite passes without
+    it. That reader answers with the DEFAULT board for every task in production, so stubbing it with a
+    working IR feeds the broken reader the right answer — the suite would keep passing even if its
+    call site stopped resolving. Audited across the 8 files that stubbed it (#3197): four were
+    redundant like this one, one is legitimately about the sync path, one was masking real inertness.
+    */
     getTaskWorkflowSelectionAsync: vi.fn(async () => selection),
     getWorkflowDefinition: vi.fn(async () => ({ ir: workflowIr })),
     on: vi.fn(), off: vi.fn(),

packages/engine/src/__tests__/triage-undeclared-column-rescue.test.ts

@@ -105,7 +105,14 @@ function createStore(ir: WorkflowIr, workflowId: string = WF): TaskStore {
     getTaskWorkflowSelection: vi.fn(() => selection),
     getTaskWorkflowSelectionAsync: vi.fn(async () => selection),
     getWorkflowDefinition: vi.fn(async () => ({ ir })),
-    resolveTaskWorkflowIrSync: vi.fn(() => ir),
+    /*
+    FNXC:WorkflowResolvedColumns 2026-07-31-23:59:
+    The `resolveTaskWorkflowIrSync` stub is REMOVED, and it was redundant: this suite passes without
+    it. That reader answers with the DEFAULT board for every task in production, so stubbing it with a
+    working IR feeds the broken reader the right answer — the suite would keep passing even if its
+    call site stopped resolving. Audited across the 8 files that stubbed it (#3197): four were
+    redundant like this one, one is legitimately about the sync path, one was masking real inertness.
+    */
     logEntry: vi.fn(),
   } as unknown as TaskStore;
 }