ci: publish PyPI download badges from a reliable endpoint

[omaiesh]

The README's download badges break regularly. shields.io's pypi/dm badge reads pypistats.org's /recent endpoint, which is aggressively rate limited; when it refuses, shields renders "rate limited by upstream service" and GitHub's camo proxy caches that error image, so the badge stays broken long after the upstream recovers. Measured on 20cfc30: the camo-cached image for rosetta-mcp showed the rate-limit text while a direct fetch returned 594/month.

Read pypistats' /overall series instead, which answers reliably, sum the last 30 days excluding mirrors, and publish a shields endpoint JSON to an orphan badges branch. Counts match what shields reports when it does work: rosetta-mcp 594, rosetta-cli 540.

Mirrors stay excluded deliberately. Including them roughly quadruples the number (2442 and 2008) without a single extra install, which is why pepy.tech reports "2k" for both packages.

Runs daily, on demand, and on changes to its own files. No secrets needed.

[isolomatov-gd]

I think we should restructure those badges completely:

1. Bring NPM ones
2. Bring unique cloners
3. Bring stats on usage of rosetta

[isolomatov-gd]

Thanks @omaiesh.

To fix:

• Please address the August 12 badge-restructure feedback.
• Update README.md to consume the published endpoint JSON.
• Reopen [Feature]: Restructure the README badges (NPM, unique cloners, usage stats) #253 — none of its acceptance criteria shipped.
• Fail loudly instead of publishing a silent 0/month.
• Fix the window: the cutoff spans 31 days.
• Align setup-python to v6; add timeout-minutes.

On the second: README.md is never touched, so nothing consumes the published JSON. Merging as-is leaves the badges broken and adds an orphan badges branch nobody reads. On the fourth: an empty or all-stale data array yields count=0, which gets committed and rendered as authoritative — worse than a visible error, and this PR exists precisely because that endpoint degrades. On the fifth: date >= today-30 admits 31 distinct dates, about 3.5% inflation against live data.

There is also a direction conflict to settle first: this PR publishes to an orphan badges branch, while #253 specifies docs/web/assets/data/*.json over GitHub Pages. Worth agreeing which one before more work goes in.

What checks out: the premise holds — I confirmed /api/packages/<pkg>/overall?mirrors=false answers reliably. The git plumbing is correct too; I traced actions/checkout to confirm the default refspec survives, so switch --force badges works on repeat runs.