[Jaro-c]

The problem

schedule-freshness.yml justifies its gh api call by describing an enforcement action against
the organisation account:

# `gh api` is banned for the maintainer's own credentials — the org
# account has been suspended over raw API traffic before.

This repository is public, and my documentation standard keeps internal operations detail out of
anything a third party reads. It also does not help the reader it was written for: someone
auditing this file needs to know the call is correct because it runs as a job-scoped token. Why
I hold a rule about my own credentials is a different fact and not theirs to need.

This is the source copy. I found it while cleaning the same text out of apt, homebrew-tap
and scoop-bucket, which took it from here when they copied the reusables in. podup has it
too and is fixed separately. Every repository that copies a reusable out of here from now on
would inherit it, so this is the copy that stops the spread.

What I changed

The comment only. No run: line, env:, permissions: block, input or trigger is touched, and
the replacement says the same thing in the terms a consumer actually needs.

The tag question, which I am not deciding here

This changes the bytes of a reusable's surface without changing its behaviour. The rule in
standards/ci is that a semver tag marks a behaviour change for consumers rather than the fact
that something shipped, so on that reading this does not earn one. It does mean pin-policy
will see a byte difference for anyone pinned here.

The blast radius is one repository: I checked every repo in the org and authcore is the only
one still referencing schedule-freshness remotely. The three distribution channels and podup
carry their own copies now.

What I checked

No occurrence of "suspend", "banned", "ban" or "this machine" is left in the file, and it still
parses as YAML.

Signed-off-by: Jaro-c 75870284+Jaro-c@users.noreply.github.com