docs(task-revert): the recorded conversion "blocker" is a correctness boundary, not a cost (#2868)

`findOpenUndoTaskForSource` carries a note saying its conversion is
blocked on **hoisting the flags derivation** in `TaskDetailModal` —
framed as a hook-ordering cost in a 5000-line component, i.e. something
somebody could pay. I went to pay it, and the framing is wrong in a way
that would have produced a **worse defect than the literal**.

## Why hoisting would not unblock it

This function scans the `tasks` list for **other** tasks pointing back
at the source, so the column it classifies belongs to a **neighbour**.
`detailColumnFlags` describes the **modal's own** task — its own FNXC
note says exactly that, and it is guarded by `detailFlagsAreForThisTask`
*precisely because* using it for anything else is wrong.

So supplying it here would answer *"is this neighbour finished?"* with
the modal task's traits. On a project where two workflows reuse a column
id, an open undo task gets classified by a workflow it does not belong
to, and the "Undo task" affordance vanishes or persists wrongly.

**Wrong flags are worse than a stale vocabulary.** The literal is at
least uniformly legacy; this would be wrong *on data*. It is the
flags-for-the-wrong-row shape — the same question I have been applying
all program: *do these flags describe the column of the row this guard
is about?*

## What a correct conversion needs

Per-**neighbour** flags: the caller would have to resolve each
candidate's own workflow, which the modal does not have and should not
fetch mid-render. Until a per-task lane map exists at that call site,
**the literal is the right answer**.

## Why this is worth a PR rather than silence

The previous note is an invitation. Somebody following it would land a
plausible-looking conversion, drop the census count by one, and
introduce a data-dependent bug that only appears on multi-workflow
projects — the exact "conversion that scores as a win" pattern
documented in `docs/solutions/workflow-learnings/`. The census entry
stays and is now labelled as **accurate debt** rather than a missed
conversion.

No behaviour change; comment only. Dashboard app `tsc` clean, `pnpm
lint` clean, `app/utils` suites 59 files / 689 tests green.

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

packages/dashboard/app/utils/taskRevert.ts

@@ -94,9 +94,27 @@ export function findOpenUndoTaskForSource(tasks: readonly Task[], sourceTaskId:
     and the behaviour was the legacy fallback forever.
 
     Reverted rather than left as a dead seam. An unsupplied optional parameter is strictly worse than
-    the literal — the literal is at least honest, and the census keeps pointing here. Unblocking it
-    means hoisting the flags derivation above that call, which is a hook-ordering change in a
-    5000-line component (same blocker as the near-duplicate gate in that file).
+    the literal — the literal is at least honest, and the census keeps pointing here.
+
+    FNXC:WorkflowResolvedColumns 2026-07-30-20:50 (correcting the unblock recorded above):
+    HOISTING THE FLAGS WOULD NOT UNBLOCK THIS — IT WOULD INTRODUCE A WORSE DEFECT.
+
+    The note above says the blocker is hook ordering, i.e. a cost. It is not: it is a correctness
+    boundary. This function scans the `tasks` list for OTHER tasks pointing back at the source, so the
+    column it classifies belongs to a NEIGHBOUR. `detailColumnFlags` in TaskDetailModal describes the
+    MODAL'S OWN task, and its own FNXC note says so explicitly — it is guarded by
+    `detailFlagsAreForThisTask` precisely because using it for anything else is wrong.
+
+    So supplying it here would answer "is this neighbour finished?" with the modal task's traits: on a
+    project where two workflows reuse a column id, an open undo task would be classified by a workflow
+    it does not belong to and the affordance would vanish or persist wrongly. That is the flags-for-
+    the-wrong-row shape, and it is worse than the literal because it is wrong on data rather than
+    merely stale on vocabulary.
+
+    A CORRECT conversion needs per-NEIGHBOUR flags — the caller would have to resolve each candidate's
+    own workflow, which the modal does not have and should not fetch mid-render. Until a per-task lane
+    map is available at that call site, the literal is the right answer and the census entry is
+    accurate debt rather than a missed conversion.
     */
     if (candidate.column === "done" || candidate.column === "archived") {
       continue;