fix(media): keep the media conn when a download is expired or refused
Fixes #1658. A download rejected with 403, 404 or 410 cleared the cached MediaConn and sent its own forced media_conn IQ. Expired files answer exactly that, so a few old stickers downloaded at once became a burst of uncoalesced IQs, the server answered 429 rate-overlimit, and an upload started at the same moment had no cached conn and failed with the same 429.
Downloads now refresh the media conn only on 401. 403, 404 and 410 are final NotFound rejections with no IQ, which is what WA Web does: WAWebMmsClientMmsDownload maps 403/404/410 to MediaNotFoundError or MMSForbiddenError, WAWebMmsClientIsErrorRetryable retries neither, and the download path never forces a media_conn refresh (details and bundle offsets in the issue). Uploads keep refreshing on 401/403. The public classification is unchanged, all four statuses still surface as ReferenceRejected with their status, but a 403 now reads Download media not found/expired with status: 403.
The tests that drove the refresh path with 403 or 410 now use 401, and an_expired_reference_fails_without_refreshing_the_media_conn checks that 403, 404 and 410 against a real socket leave the cache alone and never ask for a forced refresh. On Linux, cargo fmt --all --check, both clippy commands from CI (--all-targets, and --workspace --exclude e2e-tests --all-features --all-targets, with -D warnings), and cargo test -p whatsapp-rust --lib with and without ureq-client plus --doc pass. I used cargo test, not nextest.
I also built ZapFast 0.19.0 against this change on f7468ae and used it with a real account after 30 idle minutes. Opening the sticker picker failed 13 stickers at once with no 429, and sending a sticker right away worked. The unpatched build, after the same 30-minute wait, got four 429s as the picker opened and failed that first send.