Site audit fixes: download counter, winget alignment, chromedriver bump

[fstubner]

Three independent commits from the site audit, separated so any one can be dropped.

1. Download counter only claims a total once both sources report

renderDownloads sums GitHub release assets and crates.io, but wrote the label as soon as either resolved — so "total" was asserted before it was true. Measured on the running site: the same page showed Downloads: 178 total with only crates.io in, and Downloads: 2,635 total once the GitHub count landed. A fifteenfold difference under one label.

The fix tracks whether each source has settled separately from its count, because a rate-limited source never sets a value and gating on the counts alone would leave the label waiting forever. Settling happens in .finally, so a failed or rate-limited fetch settles too.

Verified in both directions by forcing the crates.io fetch to fail:

State	Rendered	aria-label
Partial	2.4K+ downloads	Downloads: 2,458 so far; one source has not reported
Complete	2.6K+ downloads	Downloads: 2,636 total

The partial case is the one that matters — before this change it read 2,458 total. The sabotage was reverted and the complete state re-confirmed.

While measuring this, the split between the two sources turned out to be roughly 2,458 binary downloads against ~178 cargo installs. Every package manager — winget, Scoop, Homebrew, AUR — pulls the GitHub release asset, so all of them land in the first number.

2. Short winget identifiers in the install docs

The landing page and FAQ said winget install netscli; the install docs said winget install fstubner.netscli. Both resolve, so this was inconsistency rather than error, and the short form is what the landing page leads with. All 13 winget commands across the site now match.

The full identifiers stay documented in one line, because a bare name match can become ambiguous if another netscli ever enters the catalog and fstubner.netscli cannot.

3. chromedriver 152 — correct, but unverified here

visual:check drives Chrome through chromedriver. The pinned 151 crashes against the installed Chrome 152 with a GetHandleVerifier stack trace rather than failing cleanly, so the gate reported nothing at all — neither pass nor fail.

This bump is not proven to fix it. The sandbox on this machine records the lockfile change but discards the postinstall binary download, leaving chromedriver.exe at 151 on disk. The change is correct for a clean npm ci; it has not been observed working. Drop this commit if you would rather bump it somewhere it can be tested.

What this PR does not cover

visual:check still has not run, so there is no visual-regression evidence for the counter or winget changes. The baseline (240 images, 5 Sept) is intact, and a legitimate diff on /docs/install/ should be expected from commit 2 when it does run.

Related

The first commit here is already applied to the site template as its own commit in fstubner/product-site-template#26, since that PR touches the same file. Once this lands, a later template sync should carry it across as a no-op.

Audit coverage behind these fixes

All 14 routes walked at 1440, plus mobile (375) and tablet (768) passes, light and dark themes, and a keyboard pass. Automated gates all clean: axe 0 violations across 14 pages in both themes, contrast sweep passing on every rendered text node, 0 shadowed CSS declarations of 1,116, check:regions clean, changelog dates matching. Docs search verified against a production build — packet capture returns 10 results with /docs/packet-capture/ top.

[github-actions]

Site preview: https://pr-396.netscli-site-preview.pages.dev

Built from 7f39959 with NETSCLI_PREVIEW=1 — noindex, and analytics disabled so it does not report into netscli.com's numbers.

Production is unaffected: netscli.com is served from GitHub Pages via pages.yml, which is manual-only.