fix(gh-r): musl detection is true whenever curl is installed

[ss-o]

Problem

In .zi-get-latest-gh-r-url-part (install.zsh:1653) the musl check is:

if (( ${+commands[curl]} )) || find /lib/ -maxdepth 1 -name '*musl*' >/dev/null 2>&1; then
  HAS_MUSL='linux-musl'
fi

The first operand tests whether curl is installed, which has nothing to do with libc. On any host with curl, including ordinary glibc Linux and macOS, HAS_MUSL becomes linux-musl and the find probe never runs.

The asset filter at install.zsh:1734 (${(M)list[@]:#(#i)*${~HAS_MUSL}*}) then narrows the candidate list to musl assets whenever more than one asset is still left. Checked in isolation: with HAS_MUSL=linux-musl and the assets tool-x86_64-unknown-linux-gnu.tar.gz and tool-x86_64-unknown-linux-musl.tar.gz, only the musl asset survives. So a gh-r install on a glibc host picks the musl build whenever a release publishes both. The filter only applies when it leaves at least one match, so it does not cause "no asset found".

Found by reading the code, with the filter step checked in isolation; not reproduced against a live release.

Change

Drop the commands[curl] operand so HAS_MUSL is set only when the host actually uses musl (the existing /lib/*musl* probe, or ldd --version). Also consider whether the anchored */$HAS_MUSL pattern at install.zsh:1710 can match any real asset URL at all.

Found during the 2026-09-30 whole-file review of install.zsh.

[ss-o]

Project 28 triage pass. Blank values filled on this issue (existing values left unchanged):

• Item Type: Bug. musl detection is true whenever curl is installed.
• Impact: High. On any host with curl, a gh-r install picks the musl asset whenever a release publishes both builds, which covers most gh-r users.
• Effort: XS. Remove one operand at install.zsh:1653.
• Priority: P2 - Medium. The reach is wide, but the issue shows no failing install and was not reproduced against a live release, so the band is Medium rather than High.
• Workstream: Human delivery. Ordinary manager bug.

[ss-o]

Next action: review of PR #581, which fixes this on next. There was a second cause besides the curl operand: find /lib/ -maxdepth 1 -name '*musl*' exits 0 even when nothing matches, so the probe could never be false. The fix globs /lib for the musl loader instead. A regression test shows that installing curl no longer changes the chosen asset and that a glibc host picks the gnu build. The :1710 anchored filter only matches a whole file name of linux-musl or $MACHTYPE, so it is a no-op on real archive names and is left unchanged. After merge into next, this stays open until next is promoted to main.

[ss-o]

Next action: none until promotion. The fix merged into next via #581 (merge commit 75d722c). Close this by hand when next is promoted to main, per the branch model in AGENTS.md.

[ss-o]

Project 28 triage pass (2026-10-02): stays in Triage.

• Premise check on next at 3fa8433 (premise not confirmed: the reported problem no longer reproduces): Fixed on next: lib/zsh/install.zsh:1629-1666@3fa8433 adds .zi-has-musl-loader and sets HAS_MUSL only via .zi-has-musl-loader /lib; the curl operand is gone; tests/gh-r-musl-detection.zsh exists. PR fix(gh-r): detect musl from its loader, not from curl (#576) #581 merged into next 2026-09-30. main@4f2c0a7 has no musl-loader (grep count 0), so per the branch model the issue stays open until the next promotion.
• Proposed disposition: close as completed. Settled by fix(gh-r): detect musl from its loader, not from curl (#576) #581. Closing is the maintainer's decision.
• Unknowns and next investigation: No work left; close by hand at the next next-to-main promotion (maintainer closure authorization). Not Todo: nothing to start.