Add sample-level meter model for charger health diagnostics

Problem

The current meter pipeline rolls OCPP MeterValues up to two grains:

- int_meter_values — aggregates per full transaction (min/max/avg/_count per measurand/unit/phase).
- fact_interval_data — aggregates per 15-min bucket (avg_value + _count only, shaped for rebates reporting).

Neither preserves per-sample resolution. Real chargers emit MeterValues every 30–60s (MeterValueSampleInterval), so short-lived events — voltage sags, current
oscillation, transient power drops, brief SoC stalls — are averaged away before they reach any consumer.

Proposal

Add an intermediate model (working name int_meter_samples) that exposes one row per (charge_point_id, transaction_id, connector_id, measurand, unit, phase,
meter_timestamp) with the raw value, sourced from the same unnesting logic already used in int_meter_values / fact_interval_data.

Downstream, build a diagnostics-oriented mart (e.g. fact_meter_samples or a session-health view) that supports:

- voltage sag / over-voltage detection
- current spikes and phase imbalance
- power ramp anomalies and mid-session drops
- SoC stalls

Scope

- New incremental model int_meter_samples (same incremental window pattern as int_meter_values).
- Tests: PK = the full sample grain; not_null on keys; accepted_values on measurand/unit.
- Documentation + a short README note on when to use the sample model vs. the 15-min mart.

Non-goals

- No changes to fact_interval_data (rebates pipeline stays as-is).
- No semantic-layer metrics in this issue — diagnostics dashboards can come in a follow-up.

Notes

- Sample-level data is larger; cluster by ingested_ts and consider a retention policy if cost is a concern.
- Once int_meter_samples exists, the unused min_value / max_value / avg_value / _count on int_meter_values can be removed in a separate PR — they're currently not consumed anywhere.