fix(running-in-ci): recheck immediately before the post, and count sweeps as siblings

[tend-agent]

Two bot comments answering the same freshly-filed issue, 18 seconds apart, with independently-derived but substantively identical content. Every dedup guard in running-in-ci was followed; the guard for comments just doesn't say when to run the re-fetch, and the sibling guard for gh pr create 100 lines up does.

The race, from the two session logs

Issue opened 08:20:35Z by an outside consumer's bot. tend-triage fired on issues: opened and queued. The scheduled tend-review-runs run, already in session since 08:10:33Z, found the same issue in its survey at 08:22:24Z and started composing an answer to it.

Time (UTC)	Actor	Event
08:20:35	—	issue opened
08:20:37	tend-triage	run created; job queued 5 m 08 s
08:22:24	tend-review-runs	reads the issue during its survey
08:25:45	tend-triage	job starts
08:29:03.977	tend-review-runs	dedup recheck — gh issue view … --json state,comments → 0 bot comments. Correct at that instant.
08:29:07.764	tend-triage	gh issue comment → first comment
08:29:20.818	tend-review-runs	greps its composed body for placeholders, scans its URLs
08:29:26.006	tend-review-runs	posts → second comment, 18 s after the first

The recheck was 22 seconds stale by the time the post went out, and the work that consumed those 22 seconds was the pre-post hygiene the same skill file asks for — compose the body, grep it for PLACEHOLDER/<SHA>/<TODO>, check every github.com/ owner. Moving the recheck after that hygiene would have caught it: the triage comment existed from 08:29:08, a full 18 seconds before the post.

Change

Two sentences in Recheck Before Posting, no new section:

• Ordering. Say the re-fetch runs as the last step before the post, and name the body-composition/placeholder-grep/link-check work as the gap it has to close. This is the rule the file already states for the sibling path — "Re-run the check as the last step before gh pr create" — applied to the comment path, which currently says only "before posting".
• Who the sibling can be. The bullet listing pre-empting workflows names only tend-mention, tend-triage, tend-review. The run that duplicated here was a scheduled sweep, and a reader of the current list would reasonably conclude sweeps aren't in scope. Widen it to "every workflow posts as the same bot account", and call out the sharpest case: tend-triage owns issues: opened, so a sweep already in session that finds the same fresh issue is racing a run that already owns it.

Not proposed here: a positive in-flight check (query actions/runs for a concurrent tend-* run on the same subject before posting) — the notifications skill has one and it would also have caught this. That's a new guard on every posting path rather than an ordering clause on an existing one, so it needs more than one occurrence behind it. Recorded in the evidence log instead.

Gate assessment

• Confidence: 1 occurrence, no prior instance of this shape in the evidence log for this target. Structural — no decision point anywhere in the chain: the skill text does not order the recheck relative to the post, so replaying the same two runs produces the same gap every time.
• Classification call, stated so it can be pushed back on. I filed at 1 occurrence by reading the outcome as Critical rather than High — the wrong output shipped publicly, on an outside contributor's issue, and duplicate unsolicited comments are the specific thing the conduct rule names. The alternative reading is High (2–3 occurrences), which would mean recording this and waiting for a second one.
• Magnitude: two sentences inside an existing guard, one of them restating a rule the same file already applies to gh pr create. Lowest bar on the Gate 2 table, and the reason I was willing to act on a single occurrence — the cost of being wrong here is one clause.

Adjacent but distinct, checked for overlap: #865 / #870 cover a review landing while a session polls its own PR's CI; #867 covers tend-ci-fix not seeing a sibling's tracker. Neither touches this section or this race.

Evidence log: https://gist.github.com/e08f6e62d6478163cb425a75648eb7e4

[tend-agent]

One suggestion inline. The ordering clause reads well and the cross-reference to the gh pr create rule is accurate — that rule does say "as the last step before gh pr create", and it does sit above this section. tend-nightly, tend-review-runs, tend-notifications and tend-triage's issues: opened trigger all check out against generator/src/tend/workflows.py and the generated workflow files.