fix(ci): say when the tap is being left a version behind (#390)

`releases/latest` excludes prereleases and drafts, which is the right
policy: `brew install` must not hand a user a prerelease. What it cannot
do is notice that it has answered a stale question.

This job triggers on the Release workflow completing, and the step that
promotes a prerelease to a full release lives inside that same workflow.
If that promotion does not run, or fails, or the release is a deliberate
prerelease, `releases/latest` returns the previous version, the formula
already matches it, and the push step exits 0 with "nothing to push". A
green run that moved nothing.

Not hypothetical. Run 32688159260 resolved v0.25.0 while v0.26.0 sat
published-as-prerelease, reported success, and left the tap a version
behind with nothing in the log to say so. The promotion had failed
silently, which #388 fixed, but the silence here is its own defect and
outlives that one cause.

Resolution is unchanged. Added is a warning naming both tags when a
newer published release exists that this job is declining to serve, and
an error, rather than a raw 404 from `gh`, when there is no full release
at all. A warning and not an error for the first, because refusing to
publish a prerelease to `brew` users is correct behaviour and only the
silence was wrong.

Verified against the live API on all four branches: a dispatch with an
explicit tag, a repository whose releases are all full (all-smi, resolves
v0.26.0 quietly), a repository whose newest published release is a
prerelease (backend.ai-go, warns that v1.13.0-beta.1 is not being served
and the tap stays at v1.12.1, where the old code resolved v1.12.1 with no
mention of it), and a repository with no release at all.