download/list-versions fail with HTTP 403 on Windows because kbsync is never generated (~6s, no cache written)

Summary

On Windows, download (and list-versions, which uses the same endpoint) fails with HTTP 403 empty or non-plist body for every app, including apps the account already owns — Apple's own "Apple Support" app included.

The cause appears to be that kbsync is never generated on this machine. It fails fast (~5.7 s), so this is not the 1-minute sapGuestTimeout problem from #631: nothing is cached, kbsyncGenerator stays nil, the code takes the /r/redownload fallback, and Apple rejects that request.

This is likely the same root cause as #634 / #635 (incomplete store emulator), but the user-visible symptom is different and currently undebuggable — --verbose prints nothing from the emulator, only the final 403.

Environment

• ipatool 2.7.0, official windows-amd64 release (ipatool-2.7.0-windows-amd64.exe)
• Windows 11, PowerShell 7
• Apple Account: CN storefront (id 143465), authenticated successfully
• Unicorn 2.1.4 runtime: present and loaded (%LOCALAPPDATA%\ipatool\unicorn\2.1.4\d8f9a892...\libunicorn.dll, SHA-256 matches the cache key)
• Apple frameworks in %LOCALAPPDATA%\ipatool\sap\apple-assets-v2: CommerceCore, CommerceKit, CoreFP, CoreFP.icxs — all fetched during login

What works

What fails

Every download attempt, including for apps already owned:

$ ipatool download -b com.autonavi.amap --platform iphone -o downloads --keychain-passphrase ***
downloading   0% |  | ( 0/ 1 B)
ERR  error="failed to send redownload request: unexpected response from Apple (HTTP 403): empty or non-plist body" success=false

$ ipatool list-versions -b com.autonavi.amap --platform iphone --keychain-passphrase ***
ERR  error="failed to send redownload request: unexpected response from Apple (HTTP 403): empty or non-plist body"

Timing: 5.7 s to failure (measured with Stopwatch). --verbose produces the same single line — no SAP/emulator diagnostics.

Evidence that kbsync is never generated

~/.ipatool contains only:

account   (890 B)
cookies   (5.4 KB)

There is no kbsync-v1 entry in the keychain after dozens of attempts, which matches #631's description of storeKBSync never being reached. With no kbsync, pkg/appstore/appstore_download_product.go takes the else branch (fetch URL bag → /r/redownload), and Apple answers 403.

Ruled out

• Not app-specific: Apple's own Support app (com.apple.supportapp, owned since 2026-10-24) fails identically.
• Not storefront mapping (#632): CN store front 143465 exists in pkg/appstore/storefront.go; search / list-purchases return CN results correctly.
• Not the #631 timeout: we never wait ~60 s; failure lands in ~6 s.
• Not the account: same account downloads normally from the App Store on a real iPhone.

Questions

1. Is kbsync generation currently expected to work on Windows at all, or is it blocked by the unimplemented imports tracked in #634 (AMSError) / #635 (-[NSURLComponents setQuery:])?
2. Could --verbose (or a --debug level) surface the emulator failure reason? Right now the fallback swallows it, so "403 from Apple" is all the user ever sees.
3. Is there a supported way to supply a pre-generated kbsync (e.g. from a paired device) so download can proceed when the emulator is unavailable?

中文摘要

Windows 上所有 download / list-versions 都返回 HTTP 403 empty or non-plist body，包括账号已购的应用（连苹果自家的 Support App 也一样）。定位到 kbsync 在本机从未生成成功（约 5.7 秒就失败，不是 #631 的 60 秒超时；~/.ipatool 下也没有 kbsync-v1 缓存），因此走了 /r/redownload 回落接口并被 Apple 拒绝。怀疑与 #634 / #635 的模拟器实现缺口同源。希望确认 Windows 上 kbsync 是否可用，以及能否让 --verbose 暴露模拟器失败的真正原因。