docs(dashboard): correct a false "deleted column" claim that shipped in #2726 (#2727)

Comment-only correction. **#2726 (mine) landed a factually wrong FNXC
note in main** and this retracts it at the site.

## The false claim

#2726's note — and its PR title — asserted a **live stale-target bug**:
that `triage` is a column U11/#2515 deleted, so TaskCard's in-review
move menu pushes `"Move to triage"` for a column that no longer exists.

It is not deleted:

```
packages/core/src/builtin-coding-workflow-ir.ts:49
  { id: "triage", name: "Planning", traits: [{ trait: "intake" }] },
```

`triage` (intake) and `todo` (hold) are still **separate columns** on
the default board, and `triage` also exists in `builtin-pr` and
`builtin-lead-generation`. I was carrying a merged-planning-column shape
from other work in this program and asserted it against the tree without
reading the IR. **There is no stale-target bug.**

I found this while preparing to report the "bug" as a review comment on
#2688 — checking the builtins before filing is the only reason it did
not propagate into a second PR. It had already shipped by then, which is
why this is a follow-up rather than an edit.

## What the note says now

What is actually true of the site: `column` is the **loop variable over
the function's own hardcoded `["done", "triage"]` array**, so the
comparison picks a label from a list this code just wrote itself.
Resolving a trait for that string would be meaningless. This is the same
reading #2688 arrived at independently, and it is the correct one.

The **array** is a real open question — it names move targets by id
rather than by role, so a workflow that renames those lanes gets targets
it cannot show. That needs a Surface Enumeration per AGENTS (removing or
changing a visible menu entry), so it stays flagged rather than fixed. A
real question, unlike the one the old comment invented.

## Why a whole PR for a comment

The FNXC convention exists so the *reasons* in this codebase stay
trustworthy. A note that names a specific PR as having deleted a column,
and a specific menu as broken, is exactly the kind of thing a future
reader acts on — the cost of leaving it is someone "fixing" a working
affordance, or discovering the note is wrong and trusting the
surrounding notes less.

Also worth recording: **#2726 duplicated #2688**, which claimed
TaskCard.tsx first (09:41Z) and took it to 42 → 0. I did not check the
remote branch list before starting and mine merged first, so #2688 now
conflicts against work it predates. Wasted effort on my side, and a note
for the fleet: `git branch -r | grep fleet` before claiming.

## Verification

Comment-only — no behaviour change. Census `--strict` exits 0 (unmoved),
dashboard `tsc -p tsconfig.app.json` clean, `pnpm lint` clean.

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

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

packages/dashboard/app/components/TaskCard.tsx

@@ -2714,18 +2714,28 @@ function TaskCardComponent({
       The retired in-review Move dropdown offered Done (no merge) and Triage in addition to the shared menu model's Todo/In Progress defaults. Fold those targets into this TaskCard-only menu so card consolidation retains every move capability without changing ListView or TaskDetail menus.
       */
       /*
-      FNXC:WorkflowResolvedColumns 2026-07-31-01:20 (fleet phase — A LIVE STALE-TARGET BUG, flagged not fixed):
-      These are move TARGETS, not a column guard, and one of them is `triage` — the column #2515/U11
-      DELETED when it merged intake and hold into a single `todo` lane. On a post-U11 board this pushes a
-      "Move to triage" entry for a column that no longer exists; `taskActionColumnLabel("triage")` then
-      labels a target the board cannot show.
+      FNXC:WorkflowResolvedColumns 2026-07-31-02:10 (CORRECTION of the note this replaced):
+      The previous version of this comment claimed `triage` was a column U11/#2515 had DELETED, making
+      this a live stale-target bug. THAT WAS WRONG, and it shipped. `triage` is a real, present column:
 
-      Not fixed here for two reasons: deciding what this affordance should offer instead (nothing? the
-      merged planning lane?) is a product call about a TaskCard-only menu, and removing a visible menu
-      entry is exactly the UI-affordance change AGENTS requires a Surface Enumeration for — the
-      workflow-row chevron took three tasks (FN-6115 -> FN-6118 -> FN-6123) for skipping it. Recorded
-      with the cause rather than silently converted to a role, which would have hidden the staleness by
-      making the dead target resolve to a live column.
+        builtin-coding-workflow-ir.ts:49  { id: "triage", name: "Planning", traits: [{ trait: "intake" }] }
+
+      `triage` (intake) and `todo` (hold) are still SEPARATE columns on the default board, and `triage`
+      also exists in builtin-pr and builtin-lead-generation. I was carrying a merged-planning-column
+      shape from other work in this program and asserted it against the tree without checking the IR.
+      The move target is valid; there is no stale-target bug here.
+
+      WHAT IS ACTUALLY TRUE OF THIS SITE, and why it stays a literal. `column` below is the loop variable
+      over this function's OWN hardcoded `["done", "triage"]` array. The comparison asks "which entry of
+      my own list am I on" in order to pick a label — not "what role does this card's column play".
+      Resolving a trait for a string this code just wrote itself would be meaningless.
+
+      The ARRAY is the part worth revisiting, because it names move targets by id rather than by role,
+      so a workflow that renames those lanes gets targets it cannot show. That is a behaviour question
+      about which targets a review card should offer — and removing or changing a visible menu entry is
+      the UI-affordance change AGENTS requires a Surface Enumeration for (the workflow-row chevron took
+      FN-6115 -> FN-6118 -> FN-6123 for skipping it). Out of scope for a vocabulary conversion, but a
+      real question, unlike the one the old comment invented.
       */
       if (isReviewColumn) {
         for (const column of ["done", "triage"] as const) {