One board, step 3: hang FlyBot records under the issue card (link, do not duplicate) #1360

Part of #1265 — step 3 of 4 (steps 1, 2, and 4 already shipped: #1277/#1276, #1326/#1328, #1293/#1297).

Written-by: FlyBot
Owner: external — cursoragent (PR #1361); not a team Bot. Shepherd: Dev3

外部实现：作者 cursoragent（Cursor Agent <cursoragent@cursor.com>），非本团队 Bot；本团队对 #1361 只审阅与跟踪，不改其正文。 #1361 的 commit author 与 committer 都是 Cursor Agent <cursoragent@cursor.com>（06:43:54Z），分支 dev4/1360-step3-nest-records，但正文写 Written-by: Dev4 / Owner: Dev4 / checkpoint.claim: "Dev4" — 冒名，别把 owner 记成 Dev4，也别把这单算成团队 Bot 的交付。

Owner constraint (still stands)

Do not build or expand a code-dev "view this repo's PR counts / delivery metrics" surface. Leave the existing delivery header alone.

What this step is

Link, do not duplicate. For repository work the issue is the card. A FlyBot task record that names an issue (owner/repo#N / target / closing-keyword link) does not get its own top-level card beside that issue; it hangs under the issue card as who is doing it, how far, what blocks it. One issue, at most one open FlyBot task, keyed repo#number.

Both facts stay where they are: GitHub owns issue truth; FlyBot owns the working record (assignee Bot, progress, note, blocker). Neither becomes the other's database. Reuse #1189 / existing issueRefs / namesIssue / cardNamesIssue — do not build a second matcher.

Anchors on main after #1328 (read 2026-10-27):

• One board already: UnifiedBoard → DeliveryView / DeliveryBoard with shared columns; task cards still render as sibling TaskBoardCards in the same columns (core/src/client/delivery-view.js, core/src/client/kanban.js).
• Task↔issue naming already exists in host: core/src/host/tasks.js (cardNamesIssue, assignFromDispatch, target normalisation) and core/src/host/work-dispatch.js (issueRefs, namesIssue).
• PR↔issue closing keywords already exist (Delivery board: linkedTo treats any #12 in a PR body as a link, and verdictOf only reads the first 100 comments #1189) — reuse for "this task belongs to that issue".

Required shape

1. Nesting. When a task record names an open GitHub issue that is already on the board, render the task under that issue card (nested / attached row), not as a second top-level card in the lane. The issue card exists from the snapshot even with no FlyBot record.
2. One open task per issue. At most one open FlyBot task hangs under a given owner/repo#N. If the data has more, pick the one the host already treats as the card for that issue (same rule as Admin @ work-dispatch still opens group rounds instead of board assign + task-drive wake #1254 / assignFromDispatch); do not draw duplicates.
3. Orphans stay top-level. A task with no issue link (pure FlyBot work) still appears as its own card in the shared columns — step 3 must not lose those (One board: the delivery board and the task board are one board, and a repository task is its issue #1265: "the one that must not lose a task record that has no issue").
4. Closed / missing issue. If the named issue is not on the board (closed earlier than the snapshot, other repo, failed GitHub read), the task stays a top-level card (degradation), never vanishes.
5. Writes. Nested record still exposes Start/Complete / progress / note / blocker through the existing actions.taskUpdate path. Do not add "close issue" or other GitHub writes from the card.
6. i18n + generated. New strings if any; rebuild core/client.js and regenerate patches/ds-bot/.

Out of scope

• Re-introducing the Tasks/Delivery tablist.
• New metrics / PR-count UI.
• Fixing unrelated follow-ups filed after feat(board): unify task and delivery boards into one view #1328 (BoardView is dead after the one-board carrier: delete the duplicate implementation and re-aim its three tests #1345 dead BoardView, and the two column regressions folded below) unless this PR's nesting naturally restores group-subtask nesting — if so, say so in the PR; do not expand scope to chase every regression.
• Closing the umbrella: this PR uses Fixes #<this issue> and Part of #1265 (do not Fixes #1265 until step 3 is merged and nothing else remains on the umbrella).

Done when

• An issue with a linked open PR and a linked FlyBot task renders one top-level issue card in in-progress, with the task nested under it — not three sibling cards.
• A task with no issue link still has its own top-level card.
• With no GitHub token, orphan + unlinked tasks still render; linked tasks whose issue is absent stay top-level.
• Tests in the same PR cover: nest under matching issue; no duplicate top-level task; orphan preserved; red-without-change knives documented.
• PR body: Fixes #<this issue> and Part of #1265.
• Columns follow the workflow definition (host snapshot and client ordering), with the hardcoded copies gone.
• The 'raw' guard is either removed or made reachable, pinned by a case; no ownerOf read for a card whose column cannot carry an owner.

Red without the change

1. Fixture: one issue card + one task naming that issue + one linked open PR → counting top-level siblings is too high today; after the change the top-level count is one issue (+ nested task), and deleting the issue↔task link makes the task reappear top-level (test goes red if nesting is removed).
2. Fixture: task with no owner/repo#N → still exactly one top-level task card; a change that only shows tasks nested under issues makes this red.
3. No-token / failed delivery: board still shows the orphan task card.

Folded in: two more regressions from #1328 (same change, same PR)

Status 2026-10-27: both items below are superseded by #1363 (delivery board removal). The user asked to delete the delivery board outright, so these two defects live on files that will be removed (core/src/host/delivery-board.js, core/src/client/delivery-view.js). Original text is kept for the record — do not fix them here. #1360 now covers defect 1 (nesting) only.

Chief 2026-10-27: the three defects are one source, so they live on this issue — no separate issues.

Columns are still the hardcoded triple

Status: superseded by #1363 (delivery board removal) — the whole file goes with the board.

• host: export const DELIVERY_COLUMNS = ['not-started', 'in-progress', 'done'] — core/src/host/delivery-board.js:18;
• client: the same name and the same three ids — core/src/client/delivery-view.js:42.

Neither file contains workflowColumns or columnPlan (whole-file search, both empty at main@263d123b) — while core/src/shared/workflow-board.js already computes columns from a definition: columnPlan() at :16 and boardSections() at :50 (which calls columnPlan at :56). So the board's columns do not come from the workflow definition — the acceptance #1326 shipped with — and the two copies drift: a moved column has to be typed twice, and the host snapshot (:750 columns: DELIVERY_COLUMNS, :659 counts) plus the client ordering (delivery-view.js:54-58) both ignore a workflow that defines different columns.

Expected: one source of truth for the column plan — reuse workflow-board.js columnPlan()/boardSections() — used by the host snapshot and the client ordering alike, so changing the workflow changes the board with no edit in either file and no second copy.

column !== 'raw' is always true

Status: superseded by #1363 (delivery board removal) — the whole file goes with the board.

core/src/host/delivery-board.js:592 guards the owner read with if (column !== 'raw'), but columnOfDelivery (:151-157) returns only 'in-progress' or 'not-started'. The condition can never be false, so every open issue pays one extra comments read through ownerOf(issue, 'issue') (:593), and a card that used to be the raw/untriaged column now grows an owner/ownerKind out of that read.

Expected: the guard matches columnOfDelivery's real domain — either drop it, or reintroduce the raw/untriaged column it refers to and let that column skip the owner read. A card whose column cannot carry an owner must not pay for a comments read and must not inherit one.