…tion security vulnerability

Automated security fix generated by Orbis Security AI

…teps (#5487)

## Summary
Fix high severity security issue in `.github/workflows/release.yml`.

## Vulnerability
| Field | Value |
|-------|-------|
| **ID** |
yaml.github-actions.security.run-shell-injection.run-shell-injection |
| **Severity** | HIGH |
| **Scanner** | semgrep |
| **Rule** |
`yaml.github-actions.security.run-shell-injection.run-shell-injection` |
| **File** | `.github/workflows/release.yml:113` |

**Description**: Using variable interpolation `${{...}}` with `github`
context data in a `run:` step could allow an attacker to inject their
own code into the runner. This would allow them to steal secrets and
code. `github` context data can have arbitrary user input and should be
treated as untrusted. Instead, use an intermediate environment variable
with `env:` to store the data and use the environment variable in the
`run:` script. Be sure to use double-quotes the environment variable,
like this: "$ENVVAR".

## Changes
- `.github/workflows/release.yml`

## Verification
- [x] Build passes
- [x] Scanner re-scan confirms fix
- [x] LLM code review passed

---
*Automated security fix by [OrbisAI Security](https://orbisappsec.com)*

Just (https://just.systems/) works better than make for running commands. For
example, passing arguments to `make integration-test-cli` requires a `--`
between make's arguments and the cli test runner's arguments (e.g. -sandbox),
and will also result in weird errors. Just doesn't have any of these problems.

I chose different target names than we use in the Makefile; the goal is to have
better tab completion, where the most commonly used commands can be completed
after typing a single letter. That's why I use "e2e" for integration tests,
which is not a term we use anywhere else.

Keeping the Makefile around for those who are used to it, and are too lazy to
install just.

Just (https://just.systems/) works better than make for running
commands. For example, passing arguments to `make integration-test-cli`
requires a `--` between make's arguments and the cli test runner's
arguments (e.g. -sandbox), and will also result in weird errors. Just
doesn't have any of these problems.

I chose different target names than we use in the Makefile; the goal is
to have better tab completion, where the most commonly used commands can
be completed after typing a single letter. That's why I use "e2e" for
integration tests, which is not a term we use anywhere else.

Keeping the Makefile around for those who are used to it, and are too
lazy to install just.

Normalizes the repository owner to lowercase during the PR
mapping.
This ensures that PR icons and integration features work correctly even
when the local git remote URL casing differs from the official
repository casing on GitHub.

### PR Description

Close #5494 

Normalizes the repository owner to lowercase during the PR mapping.
This ensures that PR icons and integration features work correctly even
when the local git remote URL casing differs from the official
repository casing on GitHub.

The assumption is that if a pull request exists on a main branch, it was usually
created by mistake and then closed, and showing it serves no purpose and is only
distracting.

We keep showing open pull requests for main branches though, because this allows
you to notice that there is one that you probably want to close.

This only affects the display (in the branches list and in the main view);
opening the PR in the browser using shift-G is still possible, as is copying its
URL to the clipboard.

The assumption is that if a pull request exists on a main branch, it was
usually created by mistake and then closed, and showing it serves no
purpose and is only distracting.

We keep showing _open_ pull requests for main branches though, because
this allows you to notice that there is one that you probably want to
close.

This only affects the display (in the branches list and in the main
view); opening the PR in the browser using shift-G is still possible, as
is copying its URL to the clipboard.

When no base repository is configured using gh, we have several heuristics for
choosing a likely base repo before prompting the user. One of these was that if
the origin remote exists, we'd choose that. This may be the right choice in some
cases, but in many others it's not; for example, in the common scenario of a
forking setup where the upstream repo's remote is called after its owner, and
the fork remote is called origin, we would choose origin as the base repo, which
results in not showing any PRs. Don't do that, and instead prompt the user for
the base repo in this case.

When no base repository is configured using gh, we have several
heuristics for choosing a likely base repo before prompting the user.
One of these was that if the origin remote exists, we'd choose that.
This may be the right choice in some cases, but in many others it's not;
for example, in the common scenario of a forking setup where the
upstream repo's remote is called after its owner, and the fork remote is
called origin, we would choose origin as the base repo, which results in
not showing any PRs. Don't do that, and instead prompt the user for the
base repo in this case.