Updater ignores outer timeout during commit archive download on slow links

[huangruiteng]

Problem

loopx update apply --ref main --timeout-seconds 600 can still fail deterministically while downloading the selected commit archive because scripts/install-from-github.sh fixes the archive transfer to curl --max-time 120 --retry 2 --retry-max-time 150.

The outer updater timeout covers the bootstrap and installer process, but it is not propagated into the inner commit-archive transfer. Increasing the documented CLI timeout therefore does not help a slow but progressing link.

Reproduction

On macOS arm64, upgrading a release snapshot from LoopX 1.0.5 to main@74b62ebb:

1. loopx update apply --repo huangruiteng/loopx --ref main --timeout-seconds 180 exits 124 before activation.
2. Retrying with --timeout-seconds 600 downloads the bootstrap successfully, then the inner archive transfer times out twice after 120 seconds, each time after receiving about 7.8–8.0 MB of a 33.1 MB archive.
3. The updater correctly reports changes_applied=false, retains the previous release, and does not activate a partial snapshot.
4. Installing the already-fetched exact commit through the documented clean-checkout install-local.sh path succeeds, so the blocker is the transfer budget rather than build or doctor failure.

Expected

An explicit outer timeout should bound the whole update while allowing the archive download to use the remaining budget. Slow but advancing downloads should not restart from zero on every retry.

Possible direction:

• pass a bounded remaining installer budget into the inner archive fetch;
• use a resumable private partial file when the server supports ranges, while retaining exact archive/source qualification before execution;
• keep the existing fail-closed behavior and changes_applied=false receipt when the total budget is exhausted;
• add a test proving that a larger outer timeout changes the inner transfer allowance without exposing URLs, headers, or proxy credentials in diagnostics.