#179: Add date filters and grouping to volunteer application analytics

[Nishu2000-hub]

Summary

Closes #179 — Phase 1

Adds independent date filtering to both charts in
volunteer_application_analytics.py.

Changes

• New helper: build_date_filter_trend(event) — 7D/30D/1Y/All/Custom
  filters for the activity trend chart (reads time_range,
  start_date, end_date)
• New helper: build_date_filter_location(event) — same filters for
  the location chart (reads time_range_location,
  location_start_date, location_end_date)
• New helper: get_grouping(time_range) — daily grouping (YYYY-MM-DD)
  for 7D/30D/Custom, monthly (YYYY-MM) for 1Y/All
• get_volunteer_activity_trend() now uses both helpers across all
  three queries (new, active, cumulative)
• get_volunteers_by_location() uses build_date_filter_location() —
  date filter only, no grouping, country aggregation untouched
• Response key renamed "month" → "period" per spec
• Added main block loading sql/ CSV fixtures into a local DB
  for testing all 5 time-range events

Necessary changes outside the specified functions

• merge_monthly_data() updated to read row['period'] instead of
  row['month'] — it merges the Virginia and Ireland trend results,
  so leaving it unchanged would KeyError once the trend functions
  emit 'period'
• request_body passed to the four query call sites in
  lambda_handler so the helpers can read the event

Testing

• Stub harness: 29/29 SQL generation checks pass
• End-to-end: ran main against local Postgres 16 (Docker) with
  sql/ fixtures loaded into the Virginia schema. All 5 time-range
  events return statusCode 200:
  • 7D → [] (no fixture data in window — empty handling verified)
  • 30D → single daily bucket, YYYY-MM-DD format confirmed
  • 1Y/All → monthly buckets Jan–Jun 2026, cumulative totals
    consistent (8→14→18→36→42→46)
  • Custom (Jan 1–May 31) → June rows correctly excluded,
    totals drop 46→40, daily grouping confirmed
  • Ireland schema left empty — merge logic handles the empty
    region without errors
• Independent filters verified: trend and location read separate
  event keys

Note for Phase 2

The Custom branch interpolates start_date/end_date directly into
SQL as specified in the issue. Since these arrive from the API
event, this is an injection vector — suggest switching to bound
parameters (like the existing country/skill filters) in Phase 2.

Edge case handled: Custom with a missing start or end date
degrades to no filter ("") instead of generating broken SQL.