fix(P1): recompute TARBALL after fallback version walk (REQ-132)

The fallback walk (REQ-098) reassigns VERSION from the requested
release to the nearest older release carrying a binary asset, but
never recomputed TARBALL (set once at line 106 from the requested
version). The stale tarball name then flowed into:

  - grep -F "$TARBALL" SHA256SUMS  -> matched nothing (the fallback
    release's SHA256SUMS only lists the fallback tarball)
  - sha256sum -c -                 -> empty stdin -> "no properly
    formatted checksum lines found" -> REQ-132 refusal
  - tar -xzf "${TMPDIR}/${TARBALL}" -> would look for the wrong
    filename (download saved under the stale name too)

User-visible symptom (v0.14.2 latest had no asset, fell back to
v0.12.18):

  install: verifying checksum...
  sha256sum: 'standard input': no properly formatted checksum lines found
  install: error: checksum verification failed (REQ-132); refusing to install

Fix: recompute TARBALL immediately after VERSION is reassigned in the
fallback branch, so download/grep/sha256sum/tar all reference the
fallback version's tarball. ASSET_URL and SHA256SUMS_URL were already
correct (derived from the API/ASSET_URL); TARBALL was the only stale
variable.

Reproduced the exact error before the fix; confirmed end-to-end
install succeeds after (orca-v0.12.18-linux-amd64.tar.gz: OK ->
extracting -> installed). Added a bats regression test pinning
--version v0.14.2 and asserting the dry-run "would install" line
references the fallback version (not the stale pinned one).

---ci---
project: orca
phase: 1
milestone: v0.15
status: execute
decisions:
  - id: D-001
    decision: Recompute TARBALL in the fallback branch immediately
      after VERSION is reassigned, so grep/sha256sum/tar use the
      fallback version's filename instead of the stale requested
      version's.
    rationale: Reproduced the exact user error ("no properly formatted
      checksum lines found") by running grep -F "$TARBALL" SHA256SUMS
      | sha256sum -c with a stale v0.14.2 tarball name against v0.12.18
      SHA256SUMS. TARBALL is the only stale variable: ASSET_URL and
      VERSION are correctly updated from API output, and SHA256SUMS_URL
      derives from ASSET_URL. Single-line fix, minimal blast radius,
      preserves the working non-fallback path.
    confidence: 0.96
    alternatives:
      - lazy TARBALL via a function (over-engineering for one stale
        assignment)
      - move TARBALL= assignment past the fallback block (breaks
        find_asset_url which needs the requested version's name
        pre-walk)
lessons:
  - When a fallback/walk mutates one variable (VERSION), audit every
    variable derived from it (TARBALL) for the same mutation. The
    user-facing info line at 167 constructed the name inline and
    looked correct, masking that the variable itself was stale.
---/ci---

scripts/install.sh

@@ -164,6 +164,7 @@ if [ -z "$ASSET_URL" ]; then
   ASSET_URL="$(echo "$FALLBACK_OUT" | head -1)"
   if [ -n "$ASSET_URL" ]; then
     VERSION="$(echo "$FALLBACK_OUT" | tail -1)"
+    TARBALL="orca-${VERSION}-${OS}-${ARCH}.tar.gz"
     info "WARNING: falling back to ${VERSION} which has orca-${VERSION}-${OS}-${ARCH}.tar.gz."
   else
     err "could not find any release with a ${OS}-${ARCH} tarball in the last 50 releases. Check that a release exists with a linux-${ARCH} binary."