fix(mention): skip no-op tend-mention session on bot's own comments

[tend-agent]

Problem

tend-mention's verify gate has no self-loop guard for the bot's own comments. The existing bot-comment guard added in #608 only catches GitHub App / Bot accounts (github.event.comment.user.type == "Bot"); tend's bot is a PAT-based User account, so its own comments fall through to the engagement heuristics — either the bot-authored-issue short-circuit (ISSUE_AUTHOR == bot) or "bot has prior comments" — and reach the handle job, which then exits silently via the prompt's self-loop guard. A full agent session is spun up for nothing.

#608 explicitly noted this gap and left it: "Tend's own bot accounts are PAT-based user accounts (user.type == "User"), so this does not affect tend-on-tend behavior." The skill-level guard catches it, but only after paying for the session.

Evidence

Observed every review-runs window and recorded in the June tracking issue (#646). The clearest recurring trigger is the monthly tracking-issue rollover: review-reviewers creates its month's tracking issue and posts one evidence-gist link comment per repo on it, each firing a self-loop tend-mention run.

Most recent occurrence — 2026-07-01, tracking issue #750:

Run	Trigger	Outcome
28484396350	bot's evidence-gist comment on #750	handle ran, exited silently
28484464064	bot's evidence-gist comment on #750	handle ran, exited silently
28484466694	bot's evidence-gist comment on #750	handle ran, exited silently
28484464375	bot's evidence-gist comment on #750	cancelled by concurrency

Prior windows recorded the same shape (bot's duplicate-tracking notices and tracking-thread comments spinning up no-op handle sessions — #646 findings for runs 26810096874, 26941951090).

Fix

Add a guard in the verify script, right after the App-bot check, that skips issue_comment events authored by the bot itself:

if [ "$EVENT_NAME" = "issue_comment" ] && [ "$COMMENT_AUTHOR" = "<bot_name>" ]; then
  echo "should_run=false" >> "$GITHUB_OUTPUT"
  exit 0
fi

COMMENT_AUTHOR is newly wired from github.event.comment.user.login.

Ordering matches #608: it runs after the @<bot> mention check (a hypothetical self-summons is still honored) and before the bot-authored-issue / prior-engagement short-circuits that produce the no-op session. Scoped to issue_comment only — the pull_request_review self-review paths carry intentional actionable-signal handling (the empty-approval guard from #166/#608) and are left untouched.

Testing

• New test_mention_verify_skips_self_authored_comments asserts the guard is generated, COMMENT_AUTHOR is wired, and the guard sits between the mention check and the bot-authored-issue short-circuit.
• Regenerated the three mention regression snapshots.
• Full generator suite: 257 passed.

[tend-agent]

One scope gap worth a note (self-review): the guard fires only on issue_comment, but pull_request_review_comment (subscribed here for edited only) is the other event that carries github.event.comment.*, and a bot's own edited inline comment on a PR where it already has engagement takes the same generic-heuristic path (lines 166–181) into a no-op handle session. COMMENT_AUTHOR is already populated for that event, and the @-mention check on line 80 runs first, so a self-summons stays honored — extending the condition to [ "$EVENT_NAME" = "issue_comment" ] || [ "$EVENT_NAME" = "pull_request_review_comment" ] closes it for free.

Frequency is near-zero (the bot rarely edits its own inline comments, and created isn't subscribed), so this isn't a blocker — but the PR body groups this path under the "pull_request_review self-review paths [that] carry intentional actionable-signal handling," which isn't quite accurate: pull_request_review_comment has no such handling, it just falls through to the engagement heuristics. Worth either extending the guard or documenting the deliberate exclusion.

[tend-agent]

Flagging a standing-guidance conflict for a maintainer to reconcile before this lands — not a blocker.

This PR's guard keys on comment authorship (COMMENT_AUTHOR == <bot>), which is the shape tend's own review-reviewers non-issues list currently rules not the accepted shape. That entry names this exact scenario (the tracking-issue rollover self-loop, and the pull_request_review mirror variant) and says: "sender-based or commenter-based filters on tend-mention are not the accepted shape — they are the same authorship-keyed-guard pattern rejected for tend-review. The accepted shape for loop-prevention is a label-based skip … propose new filters only when there's a distinct loop risk that can't be expressed with a label."

Worth a maintainer decision because there's a real tension the reviewing bots didn't surface: the tend-review note above endorsed the guard and proposed broadening it, without referencing the standing ruling.

The reconciliation both ways

• Toward label-based (the documented shape): the highest-frequency trigger cited here — the monthly tracking-issue rollover — is fully label-expressible today: the issues carry review-reviewers-tracking / review-runs-tracking. A skip on those labels covers that subset without an authorship key.
• Toward keeping this guard: the general case ("bot comments on any thread it already participates in") isn't label-expressible, and the prompt's self-conversation guard already no-ops these — so a issue_comment && author == bot skip arguably suppresses zero legitimate work and is a pure cost optimization, which is a fair argument the non-issue doesn't fully rebut.

Either way it's a maintainer call: relax/scope the non-issue to bless this optimization, or land a label-based skip and add the ruling to the review-runs and review skills (neither of which carries it today, which is why the guard was proposed and endorsed without the conflict being noticed).

Surfaced by the hourly review-reviewers outcome audit; full evidence trail in the run's evidence gist.