refactor(python): run aggregate tools on upstream PySNC GlideAggregate

[orwellsanimal]

Summary

• Swap the internals of sn_count / sn_aggregate (scripts/python/aggregate.py) onto client.GlideAggregate(...), removing the hand-rolled Stats API plumbing (_stats_request / _parse_stats / _group_key). Signatures and the int / dict / structured-dict return contracts are unchanged.
• Pin pysnc to the fork branch carrying the upstream contribution (feat: add GlideAggregate (Stats API) support ServiceNow/PySNC#146) until it merges and ships in a release.
• Dogfoods the new GlideAggregate continuously through the repo's real consumers while the upstream PR is in review.

Validation

Verified against dev392282 at the real call sites:

• assets/summary.json — byte-identical modulo the _exported_at timestamp (model-category names + install-status labels unchanged). The display_value=true → all change in the upstream class produced identical output here.
• distribution.json — differs only by data drift since the 2026-05-15 snapshot (total_active 639→645, unclassified 627→633, both +6); structure unchanged.
• debug-pc-auto-request.py — runs clean (active 645, identity split 633/10/1/1).
• Earlier standalone dogfood: 6/6 parity vs the old implementation (scratch/pysnc-contribution/dogfood-findings.md).

Notes / caveats

• The git-ref pin installs pysnc from the fork. The fork's version string is also 1.2.1, so a runner that already has a published 1.2.1 cached will report "already satisfied" and skip the git ref — a fresh install pulls it correctly. Worth keeping in mind for CI cache behavior.
• This is the low-risk venue for the "pin to fork/git ref" approach; the production agent (whitcortex#982) stays blocked on a real release.
• Revert plan: once GlideAggregate ships in a released pysnc, swap the git ref back to a normal version pin.

Closes #8. Refs ServiceNow/PySNC#146