Help-center screenshots served from the site domain can be silently recompressed; fetch the file-storage origin for originals

When archiving reference screenshots from a CMS-hosted help center, the image URL found in the page often goes through a resize proxy (with width/height query params) or a site-domain file path. Stripping the resize params and fetching the site-domain path can still return a recompressed copy (e.g. RGB instead of RGBA, smaller byte size) rather than the uploaded original, so "original format" archives are not actually originals.

Resolve the same file path on the platform's raw file-storage origin (the CDN host that stores the uploaded file, usually a per-account storage hostname) and download from there. Verify by comparing both copies: file (bit depth / color type) and sips -g pixelWidth -g pixelHeight (macOS) or identify, plus byte size and cmp. Keep the first copies in a scratch folder (mv, not delete) until verified. Never overwrite files another process already saved: check existence before writing and compare with cmp if a re-download happened.

The site-domain path is served by an image-optimization layer that re-encodes images on the fly; only the storage origin returns the bytes as uploaded. Newer uploads may be byte-identical on both paths, older ones are not, so a spot check on one recent image is misleading.