fix: the watchers cannot open an issue in this repository

[Jaro-c]

Both watchers crashed on their first real run. Runs 32882266001 and 32882274257.

What happened

the 'Glyndor/.github' repository has disabled issues
subprocess.CalledProcessError: Command '['gh', 'issue', 'list', ...]' returned non-zero exit status 1

This repository has issues disabled, and both watchers report by opening one. The same code in podup worked and opened podup#1563, so the logic was right and only the channel was unavailable here. The findings were real and were lost with the traceback.

This was avoidable, and how it got past me

Glyndor/apt#121 — the issue this work came from — opens with the sentence "Filed here because Glyndor/.github has issues disabled". I read it and built two watchers whose only reporting channel is impossible in that repository.

It survived local verification because my stub gh succeeded. The stub modelled the world I assumed rather than the one that exists. Same shape as testing a heredoc outside the YAML that processes it: the harness was wrong, and it answered confidently.

The fix

When gh reports specifically that issues are disabled, the report goes to $GITHUB_STEP_SUMMARY and the run exits non-zero. The failure is the notification — GitHub notifies on a failed scheduled run on the default branch.

Any other gh failure still fails loudly and does not take that path. An expired token and a deliberately closed issue tracker are different problems; collapsing them would hide a real break behind a benign-looking message.

Why exiting non-zero does not contradict the never-fail rule

tooling-audit's docstring says an advisory must not fail the run. That rule exists so a third party's disclosure timing cannot block pull requests — and these workflows run on no pull request. They are scheduled only, so failing one blocks nothing. A silent success would read as "nothing found", which is the worst outcome when the report cannot be delivered.

The docstring now states this. A reader who finds an exit 1 beside a comment promising exit 0 will otherwise fix the wrong one.

Verified by running it, all three paths

case	exit	$GITHUB_STEP_SUMMARY
findings, issues disabled	1	872 bytes for pin-watch, 2369 and 16 table rows for tooling-audit
findings, gh fails with HTTP 401	1	0 bytes — the fallback correctly did not run
no findings, issues disabled	0	empty

The middle row is the one that matters: it is what stops an expired token being reported as a closed issue tracker.

22 tests pass with --network=none. ruff check and ruff format --check clean.