download: kbsync generation exceeds 1-minute guest bound on slower machines, so it is never cached and every download waits ~60 s

Summary

On slower machines, download waits about a minute in silence on every run. The kbsync generation for ent/download needs more than the fixed 1-minute guest bound (sapGuestTimeout in internal/sap/machine/machine.go), so it always times out. ipatool then falls back to the legacy download, which succeeds. Because generation never completes, storeKBSync is never reached, nothing is cached in the keychain (kbsync-v1), and every later download pays the same minute again.

Environment

• ipatool 2.7.0 (official windows-amd64 release)
• Windows 11 23H2 (10.0.22631), AMD Ryzen 3 3250U (2 cores), 6 GB RAM, about 1 GB free
• --non-interactive --keychain-passphrase ... --format json, file keyring

Steps

1. ipatool download -b com.jagex.oldschool -o out.ipa --non-interactive --keychain-passphrase <pass> --format json
2. Nothing is printed for about 60 s, then the download succeeds (about 65 s in total).
3. Repeat: the same 65 s every time. ~/.ipatool never contains kbsync-v1.

Diagnosis

With a debug build that logs the error sendPreferredDownload returns before the legacy fallback:

ent/download fell back: generate download kbsync: generate kbsync: initialize StoreAgent global context:
execute SAP guest function: unicorn emulation timed out after 1m0s

With sapGuestTimeout raised (and the 2-minute context in sendEntDownload raised to match), generation completes on the same machine:

kbsync generation took 1m50.486s (err=<nil>)

The blob is then cached as kbsync-v1, and later runs of the unmodified 2.7.0 binary finish in about 3 s.

For comparison, an Apple M4 Pro (macOS) generates kbsync in 4.4 s with the cache bypassed. Raising the Windows TCG buffer from 64 MB to 512 MB made no difference (64 s vs 67 s, peak working set 131 MB in both runs). During the 1m50s run the process used 64 s of CPU, so a slow machine under memory pressure appears to be the cause, not a hang.

Suggestions

• Make the guest bound (and the ent/download context) configurable, or allow longer on the first generation, since the result is cached afterwards.
• Or keep generating in the background after falling back and cache the blob when it completes, so only the first download is slow.
• Log a hint (for example "generating App Store token, this can take a while" or the fallback reason) instead of staying silent, since the wait otherwise looks like a hang.