feat: keep a history of the rule count, not just the current number

[sairenchristianbuerano]

The badge carries one number, so it answers how many rules there are and never how fast the pack is growing. Reporting growth meant reading the badge file's commit messages, which worked but is not a source anyone should have to use.

Two paths now record it, both taking the count from the validator's own output so they cannot drift:

validate.yml records a point whenever rules change on main, which captures every change but only when there is one.

rule-count-history.yml runs weekly and fills the quiet weeks. Without it a week with no rule changes produces no push and therefore no point, and the series cannot then distinguish no rules were added from nothing was recorded.

Counting rule ids directly in the new workflow would have avoided building the engine, and is exactly how the number went stale in three places before. There is one derivation on purpose.

The history is seeded from the badge file's own commits, so it starts with real data from 4 September rather than from today: 208 rules then, 333 now.

record_rule_count.py upserts by day, so several pushes in a day collapse to that day's final count, and a rerun after a merge is safe. It exits non-zero on an empty or unparsed count, because a silently skipped point leaves a flat line that reads as a quiet week rather than a failure.