fix(ci): check the tap token before doing any work (#389)

An unusable HOMEBREW_TAP_TOKEN surfaced as git's `remote: Invalid
username or token` at the very end of the job, after it had cloned the
tap, downloaded four release assets, rewritten the formula and committed
the result. The message names neither the secret nor which of the two
places it can be set from, and the v0.26.0 release lost hours to it.

Add a step that calls the GitHub API with the token before the clone and
translates the answer:

  401  expired or revoked
  403  refused for this repository, usually SSO or a resource restriction
  404  the token was never granted the tap
  200 with permissions.push false  read-only, needs Contents:write

git reports all four identically. A local reproduction confirmed it
cannot do better: pushing with a deliberately bogus token through the
same credential helper produces byte-identical output to a real expired
one, while removing the helper produces a different message, so the git
error distinguishes neither the cause nor a bad value from a bad
mechanism.

Every message names where the secret is read from, because two places
can define it and the narrower one wins: an environment secret on
`packaging` shadows an organization secret of the same name, so rotating
the organization copy while a stale environment copy exists changes
nothing. That is what actually happened here.

This is the second step the token is exposed to, where the note on the
push step says one. A deliberate trade, recorded in the comment: one
more step holding the credential, for a failure that arrives before
anything is mutated and that names the repair. The token still reaches
no argv, no file, and no remote url. `printf` is a bash builtin, so no
process carries it in its command line, and the header goes to curl on
stdin for the same reason the push keeps it out of `-c
http.extraheader`.

Verified against the real API on all four branches: empty, bogus (401),
and a token with write access (pass).