Use Homebrew to install cortextool in the getting-started guides

[CharlieTLe]

What this PR does

The cortexproject/homebrew-tap tap now publishes cortextool, so the getting-started guides can install it with one command:

brew install cortexproject/tap/cortextool

No brew tap and no brew trust needed — brew install auto-installs the tap and auto-trusts a fully-qualified formula name.

Before this, the guides installed cortextool the hard way:

• microservices.md had per-OS wget + chmod +x + sudo mv blocks pinned to v0.17.0 (current is v0.21.1). The macOS block downloaded cortextool_0.17.0_mac-os_x86_64 even on Apple Silicon, despite a mac-os_arm64 asset existing.
• single-binary.md never installed cortextool at all — it ran it in Docker, and because a container has to reach Cortex, every command was duplicated into a Linux block and a macOS/Windows block (4 code blocks for 2 commands).

A host-installed cortextool reaches Cortex at http://localhost:9009 (single-binary) and http://localhost:8080 (microservices, via kubectl port-forward) on every platform. That collapses the Linux/macOS fork in single-binary.md to one command per step and retires the --network host troubleshooting entry.

Docker is kept as a single fallback in both guides — it is already a hard prerequisite and is the only path for native Windows without WSL2. Those fallbacks are bumped to v0.21.1.

Drive-by fix: Compose network name

single-binary.md documented the network as cortex-docs-getting-started_default, but Compose v2 derives the project name from the basename of the project directory, and Step 1 has users cd cortex/docs/getting-started. docker-compose.yaml sets no name: and .env sets no COMPOSE_PROJECT_NAME, so the real network is getting-started_default. Confirmed with docker network ls:

955b0d4daa61   getting-started_default   bridge    local

This is a pre-existing bug, not one introduced here — anyone who followed the macOS/Windows instructions got network cortex-docs-getting-started_default not found.

Testing

Ran both guides' commands against a live stack with cortextool 0.21.1 installed from the tap:

cd docs/getting-started && docker compose up -d
cortextool rules sync rules.yaml alerts.yaml --id cortex --address http://localhost:9009
# Sync Summary: 0 Groups Created, 20 Groups Updated, 0 Groups Deleted
curl -H "X-Scope-OrgID: cortex" http://localhost:9009/prometheus/api/v1/rules | jq '.data.groups | length'
# 20
cortextool alertmanager load alertmanager-config.yaml --id cortex --address http://localhost:9009
# ok, config readable back via /api/v1/alerts

Also smoke-tested the Docker fallback with the corrected network name and --address http://cortex:9009 — both rules sync and alertmanager load succeed.

misspell -error docs and the check-white-noise markdown check both pass.

Note on a separate breakage

docker compose up -d on master currently leaves cortex in a restart loop, unrelated to this PR: .env pins CORTEX_VERSION=v1.21.1, but runtime-config.yaml uses ruler_external_url and ruler_alert_generator_url_template, which do not exist in v1.21.1:

failed to load runtime config: load file: yaml: unmarshal errors:
  line 12: field ruler_external_url not found in type validation.plain
  line 13: field ruler_alert_generator_url_template not found in type validation.plain

I verified the commands above with those per-tenant overrides temporarily blanked (they are irrelevant to cortextool reachability) and left runtime-config.yaml untouched in this PR. Happy to file a separate issue/PR for the version pin.

Which issue(s) this PR fixes

N/A

Checklist

• Tested locally
• Add entry to CHANGELOG.md — docs-only, matching Restructure and enhance getting started documentation #7113 which created these guides