Add a normalized factor_role field to Indicators

Follow-up #82

Indicators carry category (e.g. "Hazard", "Exposure", "Vulnerability", "Coping Capacity", "Overall Flood Risk"). It's a mostly consistent factor vocabulary across hazard modules, but it's free text: inconsistent casing, hazard-specific root labels ("Overall Flood Risk" vs "Overall Heat Risk"), and "Coping Capacity" vs "Government Response" used interchangeably.

The frontend needs to map each factor to presentation (icon, color, ordering) and to decide whether an indicator is a 1–5 pillar score or a raw metric. It has no authoritative signal for either — only inference:

• In the heat branch of IDS-DRR-Frontend: a hardcoded switch over hazard-prefixed slugs (flood-hazard, heat-hazard, …) plus a hand-maintained allowlist of "score-style" slugs.
• What I'll be pushing soon: generalizes that to match the slug suffix (-hazard, -risk-score, -exposure, -vulnerability, -government-response (flood uses legacy bare slugs)) in lib/analytics/factor-role.ts. More robust than keying off category (free text, see above), but it still depends on the <module>-<role> slug convention holding for every deployment.

Proposal

Add a normalized, enum-like factor_role field to Indicators and expose it via GraphQL:

root | hazard | exposure | vulnerability | government_response | sub_indicator

• root = the overall risk score ("Overall Risk"); could equally be risk_score if that reads clearer.
• sub_indicator = any non-pillar raw-metric indicator, so the field is never null and consumers don't special-case absence.

The five pillar roles are hazard-agnostic — the same set applies to flood, heat, cyclone, etc. — so this is the natural decoupling point.

Populate during import: derive from category/parent via a normalization map, with an optional CSV column to override. Add a data migration to backfill existing rows.

Expose factor_role on both shapes the frontend consumes: the indicators query and the indicatorsByCategory tree nodes.

Frontend impact

Consumers key presentation and the "is this a pillar score (1–5)?" check off a stable enum instead of matching free-text category or parsing slugs. It lets the frontend retire its slug-suffix inference (lib/analytics/factor-role.ts), which in my soon-to-be-pushed-branch drives both icon/color and the 1–5 score classification, in favor of one authoritative field.

Start by locating the Indicators model, import path, migration setup, and GraphQL definitions for the indicators query and indicatorsByCategory tree nodes. Trace how category and parent are populated, then define the normalization and override behavior described here, backfill existing rows, and verify both GraphQL shapes expose factor_role for every indicator.