[BUG] install.sh ignores the version argument for the binary it downloads, making rollback impossible when the latest build crashes

What's wrong?

curl -fsSL https://claude.ai/install.sh | bash -s 2.1.139 does not install
2.1.139 using a 2.1.139 binary. The script unconditionally resolves
$DOWNLOAD_BASE_URL/latest and downloads that binary, then passes the version
argument through to the binary's own install subcommand as TARGET.

This is deliberate — the script comments that it always downloads the latest
version because that build carries the most up-to-date installer logic. That
rationale is sound in the normal case, and the design works whenever the latest
binary runs.

The problem is the failure case. When the latest build is broken on a given
platform, the version argument cannot work. The crashing binary is the one asked to
perform the rollback, so it dies before installing anything. The user is left
with no working install and no clear reason why, since the failure surfaces only
as:

Setting up Claude Code...
bash: line 226: 35176 Segmentation fault      (core dumped) "$binary_path" install ${TARGET:+"$TARGET"}
Installation was killed before it could finish (exit code 139).

So the version argument is unusable in precisely the situation a user reaches
for it. A user rolling back for a compatibility reason on a healthy release is
served fine; a user rolling back because the current release crashes on their
machine cannot be served at all, because the crashing binary is the one asked to
perform the rollback.

A second, smaller problem compounds it: the script deletes the downloaded binary
with rm -f "$binary_path" on both success and failure. After a crash there is
nothing left in ~/.claude/downloads/ to run manually or inspect, and
~/.local/share/claude/versions/ was never created, so the user has no artifact
to debug with and no obvious next step. Recovering required reading the installer
source to discover the downloads.claude.ai URL scheme and fetching a pinned
binary by hand.

Steps to reproduce

On any machine where the current release segfaults:

curl -fsSL https://claude.ai/install.sh | bash -s 2.1.139

Observe that the downloaded binary is claude-<latest>-linux-x64, not
claude-2.1.139-linux-x64, and that installation fails with exit 139.

Expected behaviour

Rollback should not depend on the health of the newest release. Preserving the
"newest installer logic" goal while fixing the failure case is possible — for
example, keep using the latest binary by default, but fall back to the requested
version's own binary if the latest one exits on a signal.

Suggested improvements

1. If the latest binary dies on a signal while an explicit TARGET was

requested, retry with that version's own binary before giving up. This keeps
the existing "newest installer" behaviour for the normal path.

1. Retain the downloaded binary on failure and print its path — it is the only

thing a user can run manually to get a real crash report.

1. On exit codes >= 128 other than 137, point users at the binary path and

suggest running it directly to capture crash output, the same way the 137
case explains the OOM killer.