Chapter Health Metrics: Implementing Automated Vitality Tracking

**Is your feature request related to a problem? Please describe.**
While exploring the backend, I noticed that our Project Health Dashboard is quite mature and provides great transparency into project activity. However, there is a significant gap when it comes to Chapters. Currently, a community member looking at a chapter has no easy way to tell if it is active, vibrant, or struggling. This lacks the "Community First" transparency we aim for, as users might try to engage with "ghost" chapters that haven't held an event in years.

**Describe the solution you'd like**
I want to extend the existing health metrics architecture to include Chapters. This involves building a backend engine that calculates a "Vitality Score" based on actual community engagement data rather than just code commits.

Key components:

- **Backend Model:** A new `ChapterHealthMetrics` model to store daily/monthly snapshots of chapter health.
- **Scoring Logic:** A Python service to calculate scores (0–100) based on:
- **Event Frequency:** Pulling from `owasp_events` to see how recently they hosted a meetup.
- **Leadership Compliance:** Checking `entity_members` to ensure they meet the minimum leader requirements.
- **Sync Recency:** Ensuring chapter metadata is up-to-date.
- **API Exposure:** Adding endpoints to serve these metrics so we can eventually show "Healthy" or "Needs Attention" badges on the chapter list and detail pages.

**Describe alternatives you've considered**
I considered just adding a simple `last_event_date` to the Chapter model, but that doesn't provide the historical trend or the nuanced "Health Score" that the Project Health system already utilizes. Reusing the existing health metrics pattern is more scalable and maintains consistency across the platform.

**Are you going to work on implementing this?**

- [x] Yes
- [ ] No

**Additional context**
Since the Project Health logic is already well-defined in `backend/apps/owasp/models/project_health_metrics.py`, I plan to follow that established pattern. This will complete the "Community Health" vision by bringing Chapters up to the same level of technical maturity as our Projects. It directly supports our goal of being a community-first platform by helping members find active local groups.

Start by reading backend/apps/owasp/models/project_health_metrics.py to understand the existing Project Health pattern, then inspect the owasp_events and entity_members data used by chapters. Define what the ChapterHealthMetrics snapshots and 0–100 scoring require before implementing the service and API endpoints. Done means chapter vitality metrics can be calculated and served for future health badges.

Written by the indexing model from the issue text.