Autogenerated by [a scheduled GitHub Action](https://github.com/Homebrew/brew/blob/master/.github/workflows/spdx.yml).

rubocops/text: forbid "go get" only in install method

Update maintainers, manpage and completions.

build(deps): bump mechanize from 2.8.1 to 2.8.3 in /Library/Homebrew

Autogenerated by the [update-man-completions](https://github.com/Homebrew/brew/blob/HEAD/.github/workflows/update-man-completions.yml) workflow.

Bumps [mechanize](https://github.com/sparklemotion/mechanize) from 2.8.1 to 2.8.3.
- [Release notes](https://github.com/sparklemotion/mechanize/releases)
- [Changelog](https://github.com/sparklemotion/mechanize/blob/main/CHANGELOG.md)
- [Commits](https://github.com/sparklemotion/mechanize/compare/v2.8.1...v2.8.3

)

---
updated-dependencies:
- dependency-name: mechanize
  dependency-type: direct:production
  update-type: version-update:semver-patch
...
Signed-off-by: dependabot[bot] <support@github.com>

utils/shfmt.sh: improve shell formatter usage

list: raise NoSuchKegError if formula exists but isn't installed

bump: skip PR check if livecheck does not return a version

vendor-install: handle native ARM running under Rosetta

This condition is always true when we've reached this branch.

GitHub.create_bump_pr: don't leak GitHub token if set via environment variable

Whenever the `sysctl` call does not match `"Apple"*`, we can be sure
that `HOMEBREW_PROCESSOR` is `Intel`, so there's no need for this
additional check.

The previous commit only prevented the installation of an Intel Portable
Ruby into `/opt/homebrew` prefix. Let's actually install an ARM64
Portable Ruby there too.

Since `HOMEBREW_PROCESSOR` is populated using `uname -m`, this will
register as `Intel` even when a native ARM install is running under
Rosetta.

Let's work around this by checking `sysctl -n machdep.cpu.brand_string`.
On my Intel machine:

    ❯ sysctl -n machdep.cpu.brand_string
    Intel(R) Core(TM) i3-1000NG4 CPU @ 1.10GHz

On Apple Silicon:

    brew@HMBRW-A-001-M1-001 ~ % sysctl -n machdep.cpu.brand_string
    Apple M1

The case of a Rosetta installation of Homebrew is already handled below
the proposed change.

Fixes Homebrew/discussions#2434.

build(deps-dev): bump sorbet from 0.5.9309 to 0.5.9318 in /Library/Homebrew

build(deps): bump unparser from 0.6.1 to 0.6.2 in /Library/Homebrew

Bumps [sorbet](https://github.com/sorbet/sorbet) from 0.5.9309 to 0.5.9318.
- [Release notes](https://github.com/sorbet/sorbet/releases)
- [Commits](https://github.com/sorbet/sorbet/commits

)

---
updated-dependencies:
- dependency-name: sorbet
  dependency-type: direct:development
  update-type: version-update:semver-patch
...
Signed-off-by: dependabot[bot] <support@github.com>

Bumps [unparser](https://github.com/mbj/unparser) from 0.6.1 to 0.6.2.
- [Release notes](https://github.com/mbj/unparser/releases)
- [Changelog](https://github.com/mbj/unparser/blob/main/Changelog.md)
- [Commits](https://github.com/mbj/unparser/commits/v0.6.2

)

---
updated-dependencies:
- dependency-name: unparser
  dependency-type: indirect
  update-type: version-update:semver-patch
...
Signed-off-by: dependabot[bot] <support@github.com>

We already redact secrets when printing the command-line invocation
itself. Make sure that stdout/stderr doesn't leak secrets either.

search: split up command into multiple methods

tests.yml: resume preinstalling subversion

Do not pass -Wl,-headerpad_max_install_names on linux

One of the more curious bugs, if you use
-Wl,-headerpad_max_install_names on linux, it tries to link a library
named "eaderpath_max_install_names" in, which causes all kinds of weird
havoc.

Most notably, gtester inside glib fails to run for bizarre reasons.
-Wl,-headerpad_max_install_names is not an option anywhere outside macos
anyway, so move it to macos only and avoid the heartache of extremely
weild bugs.

build(deps-dev): bump sorbet from 0.5.9307 to 0.5.9309 in /Library/Homebrew