tend-mention-relay's job is not gated on TEND_ENABLED

[leaf-agent]

Splitting the review relay into tend-mention-relay.yaml in 0.2.8 (#1230) dropped the pause gate on that path, and the switch to a TEND_ENABLED repository variable (#1233) did not restore it. With TEND_ENABLED set to false, every pull_request_review submission and every edited review comment on a same-repo PR still starts a relay run and still POSTs the tend-mention-review dispatch, which starts a second run.

Nothing acts on it — tend-mention's jobs do carry vars.TEND_ENABLED != 'false', so the dispatched run is skipped — but a repo that has paused tend still gets two runs per review event, and a relay job in each PR's check list.

What changed

In 0.2.7, the relay lived in tend-mention.yaml and its dispatch step was gated:

      - name: Re-enter on an admitted ref
        if: steps.tend_enabled.outputs.enabled == 'true'

In 0.2.8, tend-mention-relay.yaml's job carries only the fork filter:

  relay:
    if: github.event.pull_request.head.repo.full_name == github.repository

Every other generated workflow got the variable — tend-ci-fix, tend-mention, tend-nightly, tend-notifications, tend-review, tend-review-runs, tend-triage, tend-weekly all have vars.TEND_ENABLED != 'false' in their job-level if. The relay is the one job that does not.

Proposed fix

Add the same condition to the relay's if, keeping the fork filter:

  relay:
    if: >-
      vars.TEND_ENABLED != 'false' &&
      github.event.pull_request.head.repo.full_name == github.repository

Observed while regenerating max-sixty/leaf's workflows for 0.2.8 (max-sixty/leaf#743); leaf does not set the variable, so nothing is paused there and this is a correctness gap rather than an active problem for that repo.

[tend-agent]

The mechanics here are right, but the omission is deliberate rather than dropped. #1233 landed after the split and named this workflow in its own body — "Not checked, since they run no agent: mention-relay, the Codex credential refresher, and install-test" — recorded the rule beside TEND_ENABLED_CONDITION in generator/src/tend/workflows.py, and pinned it with the no_agent set in test_tend_enabled_variable_guards_every_agent_job. So the variable gates the jobs that can boot the agent; the relay boots none, and TEND_ENABLED=false skips tend-mention's verify job and the handle job that needs it, which is where a relayed event would otherwise be acted on.

Worth separating out what the gap actually costs, since 0.2.7 wasn't quiet either: there the relay job still ran on every review event and only its dispatch step was gated, so the runner boot a paused repo pays is unchanged. What 0.2.8 adds is the dispatch POST and a second tend-mention run whose jobs all skip. No agent starts on either path, in 0.2.7 or 0.2.8.

The durable problem your report does surface is that none of that reasoning is in the file a reader looks at. The generated relay workflow carries a long comment on the fork filter and another on contents: write, and nothing on the pause variable — so an audit of if: conditions across the tend-*.yaml set finds eight workflows with the check and one without, and no way to tell an intended exception from a regression. That's exactly the read you made while regenerating leaf's workflows, and the next regeneration would make it again. #1258 puts the rule in the template beside the if:; checks are green.

I've left the gate itself alone. Whether "paused" means "no agent boots" (today's rule) or "no tend run starts at all" is a maintainer's call — it's a one-line condition either way, but it reverses a choice that was announced and merged three commits ago, and there's no observed harm yet to argue from, since leaf isn't paused. If the answer is the stronger reading, #1258's comment is the line to edit and the no_agent set is the second.