Filter commits by date

[aboydnw]

Goal

When a user selects a time range, the visualization should reflect the actual commit count within that window — not just whether activity overlapped. Link widths, contributor node sizes, and flow visuals should all scale to the filtered commit counts. This also lays the groundwork for a future animation feature that steps through time.

Implementation Order

1. Python model change — add commit_histogram field to Link
2. Python CLI change — bucket commits by month during Link.from_github()
3. CSV generation — write commit_activity.csv in the csvs command
4. Build command — copy new CSV to assets/data/
5. Re-run data collection — python -m contributor_network data then csvs then build
6. JS data loading — load fourth CSV, build activity index
7. JS data preparation — attach histograms to link objects
8. Time range filtering — implement count-based filtering in applyFilters()
9. Scale updates — verify link widths and contributor radii update correctly
10. UI slider — build the time range control

Risks and Considerations

API rate limits: No additional API calls are needed. The commit data is already being fetched — we're just retaining the dates instead of discarding them.

Data freshness: Existing JSON files in links/ won't have commit_histogram until re-fetched. The field defaults to {} so old data won't break, but will produce empty histograms. A full re-fetch is needed for complete temporal data.

Month boundary precision: Commits are bucketed by calendar month (UTC). A commit at 11:59pm on Jan 31 and one at 12:01am on Feb 1 land in different buckets. This is acceptable for the visualization's granularity.

Scale behavior: When the time range is very narrow (e.g., one month), most links will have small counts and the scale domain shrinks. This can make thin links appear thick. Consider setting a minimum domain ceiling (e.g., 10) to prevent scale distortion on narrow ranges.

Backward compatibility: links.csv is unchanged. The new commit_activity.csv is additive. If the JS can't find it, fall back to the overlap-based filtering described in the ROADMAP.md Feature 4 entry.