feat(placement): a record you only cite carries its status (#4154)

Step 1 made placement cheap for a task whose status CHANGES: create_task
and update_task return where it sits, and the report is written from
that. It did nothing for a task a reply merely cites.

This milestone's own step-6 review reported "#4014 is the open step of
milestone 409". #4014 had been done for four days; the open step was
#4015. The id did not come from a read — it came from a retrieval hint,
which carries an id, a kind and a title and says nothing about status,
while list_milestones said "8 of 9" and would not say which one. The
gap was there to be filled and the nearest-looking id filled it.

Two surfaces, one principle: the status arrives with the id.

1. get_project_milestone_summaries gains next_step — the earliest open
   step, {id, title, status} or None — carried through _BRIEF_FIELDS to
   enter_project, get_project and list_milestones. One extra flat query
   for the whole batch, so #2384's fan-out does not come back.

   OPEN_STEP_STATUSES moves to services/milestones.py and placement.py
   imports it; both surfaces now answer "what is next" and must not
   drift on what counts as open. Both step queries take the same
   readable_notes_clause (rule 78), so a row cannot name a step its own
   progress numbers exclude.

2. _record_kind renders a task's status: [task (done)], [issue (todo)].
   A finished step and an open one read identically before, which is
   exactly the line the misreport was taken from. Only tasks — is_task
   IS status-is-not-None on the model, so there is no fallback branch.

reporting-back gains the practice, owned and registered in the guidance
ownership table: a record you only mention is a record to read.

The guards are structural and each fails on the regression it names:
the query count is asserted rather than the payload shape, and the two
surfaces' agreement is pinned on the rendered ORDER BY, since a mocked
session hands back whatever order the test chose.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01821k5B3Ysecp9fNYs92Kuy

src/scribe/services/plugin_context.py

@@ -640,7 +640,7 @@ async def get_autoinject_config(user_id: int) -> dict:
 
 
 def _record_kind(note) -> str:
-    """The one-word kind marker for an injected menu line.
+    """The kind marker for an injected menu line — and, for a task, its status.
 
     The menu is drawn from every record that carries an embedding, so a snippet,
     a stored process, an issue and a stray dev-log all arrive looking identical.
@@ -649,9 +649,24 @@ def _record_kind(note) -> str:
 
     Task-ness wins over `note_type` because it's the more useful distinction at a
     glance: "there's an open issue about this" beats "there's a note about this".
+
+    A TASK ALSO CARRIES ITS STATUS, because for that kind alone the line is
+    read as a claim about live work. A finished step and an open one rendered
+    identically is not a cosmetic gap: a done step was cited as a milestone's
+    open one on the strength of a line exactly like this, which carries an id,
+    a kind and a title and said nothing about where the work stood (#4154).
+    Only for tasks — a note or a snippet has no status to be wrong about.
     """
     if note.is_task:
-        return "issue" if note.task_kind == "issue" else "task"
+        kind = "issue" if note.task_kind == "issue" else "task"
+        # No fallback for a missing status: `is_task` IS `status is not None`
+        # (models/note.py), so a branch for a task without one could never be
+        # taken, and a dead branch is a claim about the data that isn't true.
+        #
+        # Parenthesised rather than dot-joined: the write-path prior-art line
+        # joins its own fields with " · ", so a dotted status would read as
+        # another flag beside `seen` instead of as part of the kind.
+        return f"{kind} ({note.status})"
     return note.note_type or "note"