fix(release): give the promote job a repository, and stop it failing silently (#388)

fix(release): give the promote job a repository, and stop it failing silently

The promote job added in #386 reported success while doing nothing. Run
32687874926 built and uploaded all fourteen artifacts, promotion ran, and
v0.26.0 stayed a pre-release:

    failed to run git: fatal: not a git repository (or any of the parent
    directories): .git

    v0.26.0 is already a full release; nothing to promote

The job checks out no source, by design, so `gh` had no git remote to infer
the repository from and every call failed. `GH_REPO` supplies it.

The second half is the part worth dwelling on. The failure was swallowed:

    if [ "$(gh release view "$TAG" --json isPrerelease -q .isPrerelease)" != "true" ]

A failing command substitution inside a test yields an empty string, `set -e`
does not fire there, and empty is not "true", so the guard concluded the
release was already promoted and exited 0. A step that cannot read the state
took the branch that means "nothing to do", which is the worst possible
default: it looks identical to success.

So the state is now read into a variable, an unreadable state is a hard
error rather than an assumption, and the asset listing gets the same
treatment. Refusing to guess is the whole point; a release that silently
stays a pre-release also silently stalls Homebrew, which resolves through
`releases/latest` and never sees one.

Refs run 32687874926