An issue being worked on looks the same as one nobody has touched #254

Problem

Looking at the issues list, you cannot tell which issues are being worked on right now. Almost every open row shows the same plain blue circle, and issues go from that circle straight to closed without ever visibly passing through a working state.

The indicator is not missing. IssuePresentation.category/2 already returns :started for an open issue whose progress is in_progress, and the list already renders Circle's started arc with the label In progress. Its own moduledoc admits the shape "has always drawn and never had data for."

What is missing is anything that produces the data. Issues.progress_map/2 derives progress and stores none of it:

• closed becomes done
• open becomes in_progress only when a project board the reader can open places it in a started column
• everything else becomes to_do

Nothing in how work actually starts here touches a project board. An agent picks up an issue, works it, pushes, and closes it, and no board column ever moves. So the derivation has no input and the arc never draws. Measured against the live tracker just now: 10 of 12 open issues read to_do and 2 read in_progress.

The blue circle is simply the :open glyph. It means "open", not "untouched" — but because it is what nearly every row shows, it reads as "nothing is happening here."

Scope

Give the started state a source of truth that reflects how work really begins, and make the list say so.

In scope:

• A way for work starting on an issue to mark it started, whatever actually starts the work — an agent picking it up, a person claiming it, a linked branch or push.
• The list distinguishing started from open at a glance, without the reader hovering or opening anything.
• Keeping progress honest: an issue nobody is working must not read as started, and a stalled claim must not read as started forever.

Out of scope:

• Redesigning the issues list.
• Requiring everyone to keep a project board up to date by hand. Board columns may stay one input, but they cannot be the only one, because the workflow that produces almost all the movement here never opens a board.

Acceptance criteria

• An issue that an agent or a person has started reads In progress in the list, with a glyph distinct from both open and closed, and it gets there without anyone touching a project board.
• The same value is served by the API and rendered by the list, from one derivation, so the two cannot disagree.
• An issue that is merely open still reads open. A test covers the difference.
• A started issue that goes quiet stops reading as started rather than claiming work forever; the rule for that is written down.
• Visibility is preserved: a private board or a private claim never becomes a public fact about an issue, which progress_map/2 is careful about today.

Success metrics

• Opening the issues list during a working session, the rows being worked on are identifiable at a glance and match what is actually running.
• Over a burndown like 2026-08-25 — 65 issues to the mid-teens, a dozen agents — the count reading in_progress tracks the number of agents actually working, instead of sitting at 2 out of 12 while nine agents run.