[omartelo]

Fixes the flaky TestChromeDownloadsLandInDownloadsAndThePageStays, which failed on main (run 40584150744, macOS) and on #955. Three failures, three causes.

Linux: page load error net::ERR_ABORTED in attachment

Chrome reloads the page 1.46 to 1.70 seconds after an <a download> begins (24 samples, Chromium 155), and that reload aborts a navigation started before it. The answer was held 1.5 seconds after the download began, inside that spread, so the next browser_navigate sometimes lost the race. Product fix: downloadQuiet is now 2.5 seconds. The same race hit an agent's real next step, not only the test.

macOS and Windows: GUID-named files left in Downloads

Traced on the Windows runner: the extra files (4 KB to 33 MB) never had a Browser.downloadWillBegin or downloadProgress event. Browser.setDownloadBehavior applies to the whole browser, so Chrome's own background downloads (the optimization guide's models, which go through the profile's download manager with no page) were saved into the Downloads folder under their GUID and never renamed. In production that is the user's real ~/Downloads. Product fix: Chrome starts with OptimizationGuideModelDownloading and OptimizationTargetPrediction disabled, on top of chromedp's own disable-features list. docs/ceilings.md names the remaining trap: a background download a later Chrome adds would land the same way.

Windows: blank.csv ... State:inProgress

Test change, because the test asserted something the contract never promised. For a target=_blank download the click answers before the new tab hands over its URL, so the test polls page reads. A read names a download still running and the next read says when it ends (docs/browser-tab.md), but the loop stopped at the first read that named one. It now keeps polling until that download is no longer in progress. The assertions are unchanged: exactly one download, at the expected path, completed, with the expected contents.

Test plan

• Before, Linux: go test -count=20 -run TestChromeDownloadsLand failed 1/20, and the attr+attachment pair failed 2/40 with ERR_ABORTED.
• After, Linux: 0/30 for the whole test, 0/60 for attr+attachment, and 0/20 for the downloads live tests on the final commit.
• macOS and Windows, repeated in debug CI runs: with the old flags the strays showed up once in about 29 runs per OS (Windows, the traced run); with the new flags, none in 26 runs per OS. The base rate is too low for that to prove the fix by rate alone. The cause comes from the trace: none of those files had a download event.
• gofmt -l ., go vet ./... and go test ./... are clean.