skills(review-reviewers): mark tend-triage no-op on own tracking-issue creation as a Non-issue

[tend-agent]

Problem

review-reviewers proposed a fix (a tend-triage label-skip for the bot's own monthly tracking issues) that a maintainer rejected as not worth the complication: "The wasted runs are real, but each one no-ops through the existing self-conversation guard, so the cost is a few CI minutes a month. Against that, the skip permanently puts tend-internal label names in .config/tend.yaml plus a regenerated workflow to keep in sync. The guard already covers this case."

The pattern the fix targeted — tend-triage firing on the issues: opened event when the bot's own review-*-tracking issue is created, reading it, and exiting via the self-conversation guard — is structural and recurring (it fires every month on the 1st). The review-reviewers Non-issues list already covers tend-mention no-ops on the bot's own tracking-issue comments, but not tend-triage on tracking-issue creation. So without codification a future run will re-derive the same fix, re-open it, and get re-rejected — pure maintainer churn, which is exactly what the Non-issues list exists to prevent.

Fix

Add one Non-issue bullet marking the tend-triage-on-own-tracking-issue-creation no-op as expected behavior, and stating the accepted disposition (record as carry observations; do not propose a label-skip/filter, because the standing config+workflow maintenance outweighs the CI minutes the guard already absorbs).

Per the repo's skill-authoring rules, the bullet states the structural rule without citing the specific PR/case that produced it.

Gate assessment

• Evidence level: codifies explicit maintainer feedback (a single, unambiguous rejection with reasoning). The underlying no-op pattern is documented recurring (≥3 months of tracking-issue-creation triage runs).
• Structural vs stochastic: structural — the trigger fires deterministically on the fixed label every month and always no-ops.
• Change type: small addition to an existing list (prevents future work rather than adding behavior).
• Invisible failure mode: a re-proposal would not surface as a CI failure — it surfaces as a re-rejected PR and maintainer churn — so codification is the only thing that catches it next time.
• Passes both gates: yes.

Evidence log: https://gist.github.com/tend-agent/e08f6e62d6478163cb425a75648eb7e4