🐛 fix(dashboard): report the count window separately from the freshness window

[clubanderson]

GET /api/repo-activity advertised window_hours: 12 while the per-repo counts were accumulated over 14 days:

	Value	Source
Counts accumulated over	activityWindow = 336h	activity_collector.go:214
Window advertised	activityHealthWindowHours = 12	activity_collector.go:289

Any consumer treating Count as "output within window_hours" — an events-per-hour rate, most obviously — overstates activity by 28×.

Both values are legitimate; reporting one for both questions was the bug

The wide accumulation window is deliberate and documented: the hub computes freshness itself from NewestAt, and a slightly-late collect must not drop a just-inside-12h event. So this adds count_window_hours alongside window_hours rather than redefining either.

The hub's health verdict already recomputes recency from NewestAt and owns its own 12h constant (health_verdict.go:33-35), so it was never misled and its semantics are untouched. No clamp change was needed — sanitizeRepoActivity already tolerates 720h.

What's included

• CountWindowHours on ActivitySnapshot, populated from activityWindow
• Carried through the heartbeat (repo_activity_count_window_hours) and the hub registry, so hub-side consumers get the same disambiguation
• Stated in the endpoint's own limitations strings — a caller reading the JSON shouldn't have to find this commit
• A test pinning the two apart: equal values fail, and a count window narrower than the freshness window fails, since that would let a "fresh" event fall outside the counted range

Why this is worth fixing now rather than later

Phase 1 of the per-repo cost epic (#4836) produces these counts, and Phase 3 attaches spend to them. At that point a 28× mislabel stops being a wrong dashboard number and becomes a wrong budget figure. It also directly contradicted that epic's own stated rule that the attribution window must be reported alongside the number.

One correction to the reported scope

While adding a retention caveat I initially wrote that the audit log's rotated backups are not read. That is no longer true — OutputActionsSince reads rotated and compressed .gz backups (with a gzip-bomb cap, hardened in #4863). The limitation now states the accurate constraint: backups are read, but only MaxBackups are kept, so a busy hive's effective lookback can still be shorter than the nominal count window.

Fixes #4860

[kubestellar-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign clubanderson for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[github-actions]

Changelog: this PR changes code but does not touch CHANGELOG.md.

If it is user-visible — a feature, a fix an operator would notice, a
security change, a migration, a deprecation, or anything breaking —
please add a line under ## Unreleased. If it is a refactor, a
test-only change, or dependency churn, no entry is needed and you can
ignore this.

This is a reminder, not a gate; it never blocks a merge.

[github-actions]

Thank you for your contribution! Your PR has been merged.

Check out what's new:

• KubeStellar Console — Live multi-cluster dashboard
• Marketplace — Community extensions
• Knowledge Base — Troubleshooting and how-tos

Stay connected: Slack #kubestellar-dev | Multi-Cluster Survey