Let task agents suggest discarding their task, with reasoning

docs/operations.md

@@ -39,6 +39,8 @@ A task's summary is what its agent writes, before the task closes, about the who
 
 An implementer says its task is ready to merge with the `ready_for_merge` MCP tool (`internal/agents/ready.go`), whose `overview` covers the whole task for a human switching between tasks: a summary, tradeoffs and compromises, what was not done, and future TODOs. Its description tells the agent to call it only once the review of its most recent changes has come back, never in the same turn as a change or while that review is pending. Each call records a `task.ready` event carrying it, which the lead gets as a signal and the transcript draws as a bubble (`ReadyBubble` in `mac/Sources/Byre/Chat.swift`) headed "ready for merge". The latest one, while the task is active and neither a question nor a snapshot other than an answer snapshot has come since it (a question, or newer work the overview doesn't cover), is drawn like an open question (the warn tint and border) and carries small Merge and Discard buttons that act like the header's, confirmation dialogs included; earlier ones are drawn like an answered question (the faint warn tint), without buttons. Recording it changes nothing else. byre asks for it (`readyPrompt`, sent as a byre message) when a task's state goes to `idle` (`Manager.Observe` calls `promptReady`) and the latest non-answer snapshot's review is `done` or `skipped`, once per snapshot. It checks and sends under the session's delivery lock (the one human messages and answers take), and only to an agent that isn't running, so the prompt never queues behind a turn that could add unreviewed work; `tasks.ready_prompt_n` holds the last snapshot asked about, set only once the prompt's turn started, so turns that change no files don't ask again and a new snapshot does. It doesn't ask for workflow stage tasks, a task with a merge after review set, or a review that failed, and it skips the `reviewing` → `idle` change of a review with findings, since those go to the agent; the turn that answers them asks once it ends without new work. The prompt tells the agent not to call the tool, and to say what's left, when the task isn't ready.
 
+An implementer that thinks its task shouldn't land at all (the approach failed, the task turned out unnecessary or already done) says so with the `suggest_discard` MCP tool (also `internal/agents/ready.go`), whose `reason` explains why; `readyPrompt` offers it as the alternative to `ready_for_merge`. Each call records a `task.discard_suggested` event, which the lead gets as a signal and the transcript draws with the same `ReadyBubble`, headed "suggests discarding". It takes part in "latest" with the ready-for-merge overviews, so whichever of the two came last is the current one, drawn and cleared under the same rules, and it carries only the Discard button. It only suggests: the task stays open until the human discards it.
+
 Agents find closed tasks with the `search_closed_tasks` MCP tool, which task agents get for their own project and the lead for one project (`project_id`) or all: a case-insensitive substring match of `query` on title, merge title, TODO item, summary and merge commit (`Store.SearchClosedTasks`), newest closed first, at most `limit` (default 20, at most 100), each with its id, outcome, merge commit, close time, creator, titles, TODO item, fork source and summary. The lead reads a closed task's transcript with `read_transcript`. There is no closed-task list in the UI; the human asks the lead.
 
 **Knowledge base.** How byre features work that agents need only now and then lives in articles they fetch on demand instead of in their guidance: the Markdown files in `internal/agents/kb/`, embedded in the binary (`kb.go`). A file's name without `.md` is its topic, its first line a one-line summary and the rest the article. The `read_knowledge` MCP tool, which task agents and the lead get, lists every topic with its summary in its description and returns the article for `topic`. Adding an article is adding a file; the index follows. The articles are `signing` (turning on signed merge commits), `usage-commands` (the usage command's JSON format, see "Usage" under "Status"), `workflow-files` (a workflow's YAML, see "Workflows"; `read_workflow` and `save_workflow` point at it) and `todo-file` (the `TODO.md` format; the task guidance points at it).
@@ -317,7 +319,7 @@ Agents ask questions with the `ask_human` MCP tool. Each question carries a `con
 
 `GET /api/inbox` is one query over open items, oldest first; `project_id` and `task_id` narrow it to a project or task view, and `state` picks another state. The right pane shows a task's questions in its transcript, where they were asked, and they are answered there (below).
 
-**Attention.** At the top right of a task's transcript, over its content, a column of buttons (`AttentionBar` in `mac/Sources/Byre/Chat.swift`, counted by `ChatModel.attention`) shows what in the transcript needs the user, one button per kind that has any, in the warn colours: "N questions" for its open questions, "N findings" for the findings of the task's latest review (the highest-numbered snapshot with a `review.*` event, once it is `done`) that have neither a state from the user nor a response from the agent, and "ready to merge" while the latest ready-for-merge overview is current (see "Ready for merge"). Each click scrolls to the next one of that kind, top-anchored, and after the last back to the first. Where the transcript would follow the bottom, it follows only until the first of these rows in transcript order (`ChatModel.held`) reaches the top, and stays there as rows arrive; so a transcript opens at that row, and one that a new question arrives in stops with the question at the top. Scrolling by hand or sending a message lets that row go (`ChatModel.release`), and the transcript follows the bottom again until a different row becomes the first. A button goes away once nothing of its kind is left. When one of these rows stops needing the user (a question answered, a finding answered, the overview no longer current) and others remain, the transcript scrolls to the next remaining one after it in transcript order, wrapping to the first (`ChatModel.closed`). Elsewhere, the switcher and the Merge confirmation's question warning jump to the task's oldest open question (`Store.showQuestion`), and the review warning to that snapshot's review (`Store.jumpTo` with `.review`): each selects the task's Transcript tab and scrolls there once the row is in the transcript.
+**Attention.** At the top right of a task's transcript, over its content, a column of buttons (`AttentionBar` in `mac/Sources/Byre/Chat.swift`, counted by `ChatModel.attention`) shows what in the transcript needs the user, one button per kind that has any, in the warn colours: "N questions" for its open questions, "N findings" for the findings of the task's latest review (the highest-numbered snapshot with a `review.*` event, once it is `done`) that have neither a state from the user nor a response from the agent, and "ready to merge" while the latest ready-for-merge overview is current (see "Ready for merge"), or "suggests discard" when that latest one is a discard suggestion. Each click scrolls to the next one of that kind, top-anchored, and after the last back to the first. Where the transcript would follow the bottom, it follows only until the first of these rows in transcript order (`ChatModel.held`) reaches the top, and stays there as rows arrive; so a transcript opens at that row, and one that a new question arrives in stops with the question at the top. Scrolling by hand or sending a message lets that row go (`ChatModel.release`), and the transcript follows the bottom again until a different row becomes the first. A button goes away once nothing of its kind is left. When one of these rows stops needing the user (a question answered, a finding answered, the overview no longer current) and others remain, the transcript scrolls to the next remaining one after it in transcript order, wrapping to the first (`ChatModel.closed`). Elsewhere, the switcher and the Merge confirmation's question warning jump to the task's oldest open question (`Store.showQuestion`), and the review warning to that snapshot's review (`Store.jumpTo` with `.review`): each selects the task's Transcript tab and scrolls there once the row is in the transcript.
 
 `POST /api/inbox/responses` answers any number of questions in one submission, each becoming `answered`. Response types: