[Audit] Document or remove degenerate dimensions and implementation columns in fact_charge_attempts, fact_downtime_daily, fact_visits

## Context

Three fact tables contain descriptive attributes and internal columns that are either undocumented degenerate dimensions or should not appear in mart output at all.

**`fact_charge_attempts`** — `previous_status`, `status`, `next_status`, `transaction_stop_reason`, `id_tags`, `id_tag_statuses`, `error_codes` are descriptive attributes stored directly in the fact. In Kimball, descriptive columns that don't belong in a dimension and are not measures are degenerate dimensions — they need to be documented as such so consumers know they can filter and group on them but cannot join them to a separate dimension table.

**`fact_downtime_daily`** — `type` (OFFLINE/FAULTED) is a low-cardinality categorical attribute stored in the fact. Same treatment: should be documented as a degenerate dimension.

**`fact_visits`** — two separate problems:
- `grouping_key` is an internal implementation column (used during the visit-grouping logic). It has no business meaning and should not appear in mart output. Its presence in the final model is scope creep from the intermediate layer.
- `charge_attempt_ids` and `charge_point_ids` are arrays. Arrays in fact tables are non-standard in dimensional modeling: they prevent standard SQL joins, break most BI tools, and make the semantic layer unable to aggregate correctly. If these are needed for operational use cases, they belong in a separate wide/operational table, not in the dimensional mart.

## Acceptance criteria

- [ ] `fact_charge_attempts`: `previous_status`, `status`, `next_status`, `transaction_stop_reason`, `id_tags`, `id_tag_statuses`, `error_codes` are documented in the model's `.yml` as degenerate dimensions with a note explaining they are stored in the fact (not in a separate dimension table) and can be used for filtering/grouping
- [ ] `fact_downtime_daily`: `type` is documented as a degenerate dimension with accepted values (`OFFLINE`, `FAULTED`) and an `accepted_values` test
- [ ] `fact_visits`: `grouping_key` is removed from the mart model output (it may remain in an intermediate CTE if needed for logic, but must not appear as a selectable column in the final mart)
- [ ] `fact_visits`: a decision is documented on `charge_attempt_ids` and `charge_point_ids` — either (a) they are moved to a separate operational/wide table and removed from the dimensional mart, or (b) a written rationale explains why arrays are acceptable here and the semantic layer config explicitly excludes these columns from metric aggregations
- [ ] All existing tests pass after any SQL changes (`dbt build --select fact_charge_attempts fact_downtime_daily fact_visits`)