emrg: the promote task never reads what others are waiting on it to do, and a count it publishes is never measured #2459

What was observed

emrg/server/promote_prompt.md, the community-promotion template.

Its tracking runs one way only. A round is defined as: find new topics (§3 Step 1), join them (Step 2), follow up threads it started (Step 3), hand feedback off (Step 4). The promotion tracking field (§4.1) records "posted promotions with replies / ongoing discussions / questions awaiting clarification" — every item is an action the task itself took. Nothing in the template, and no field in the snapshot, covers the opposite direction: a thread the task already opened on someone else's repository where the maintainer has replied and is now waiting for the task to move.

Measured cost: on knight22-21/DevAgent#94, a pull request opened 2026-10-02, the maintainer replied 2026-10-10 — Everything else looks good, CI passed… conflict, could you rebase and force-push?. No round carried that sentence anywhere, so for nine days the request sat unanswered. When it was finally found, fulfilling it was small: rebase onto 5345a78, resolve one conflict in a changelog, force-push, and the pull request went from dirty to mergeable.

A published count is never measured. §3 Step 2 item 3 already requires technical claims to be verified before they are published — "technical facts in your reply must be verified, not from memory or reasoning alone". A count does not read as a claim, so it passes under that rule. On the same pull request, a changelog entry stated that tests/test_pkce_callback_port.py held "7 tests"; the file had held six since the branch was created. Nothing had counted them; the number was written from memory, and it was corrected afterwards by hand.

What the fix must satisfy

1. Reading what is addressed to the task comes before finding anything new in a round, and it names the commands — the task's own open pull requests and issues, and the last comment on each that is not its own — so it is a step a round can run, not an intention it can hold.
2. A request found there (rebase, add a test, change the wording, answer a question) is that round's first work, ahead of any new participation; a request the round cannot do goes into promotion tracking with the request itself as the to-do, rather than being dropped.
3. Every count the task publishes — in a comment, a pull request body, or a changelog entry — is one a command produced in that round and can be quoted with. A number that cannot be produced that way is removed rather than softened.

Both are additions to sections that already own their subject: item 3 extends the existing verification requirement in §3 Step 2, and items 1–2 belong to the recon step and the promotion tracking field.