Prevent transient GitHub errors from polluting release index reads

[brandonpayton]

Why

During a GitHub outage, one release-asset request can fail and a later retry can succeed. The GitHub CLI writes a JSON error body to standard output for the failed request. The current retry helper forwards output from every attempt, so the error object is joined to the later valid asset array.

That mixed stream is not real release state. It can produce malformed counts and a misleading duplicate-asset failure, which blocked PR #992 even though its complete staging test suite was green. This matters to maintainers because a retry should recover from a transient API failure, not turn the failure response into package metadata.

This is generic Kandelo release-index infrastructure. It does not change the kernel, runtime behavior, or ABI, but it is broader than a Homebrew-only change.

What changed

• Capture each GitHub command attempt in a private temporary file.
• Emit standard output only when that attempt succeeds.
• Discard failed-attempt payloads while retaining the existing error and retry diagnostics on standard error.
• Add a regression where two failed asset-list requests each emit JSON before the third request returns a valid page.

Validation

• scripts/dev-shell.sh bash tests/scripts/release-index-state.sh — passed.
• scripts/dev-shell.sh bash -n scripts/release-index-state.sh tests/scripts/release-index-state.sh — passed.
• shellcheck was not run because it is not declared in the repository dev shell.

Scope

No kernel code, ABI definition, package recipe, package revision, release asset, or generated index was changed. This PR should not receive ready-to-ship or merge under the Homebrew-only standing authority without an explicit scope decision.

[brandonpayton]

Live incident probe evidence: running the patched snapshot against binaries-abi-v41 encountered a transient 503 while listing asset page 2 and continued without polluting the parsed inventory. The later stable-index download received four consecutive 503 responses, so the command failed with the real GitHub API errors. It did not emit the old malformed-count or duplicate-asset diagnostics. This was read-only; no release state changed.