Design reliability scoring for live data answers

[galjos]

Goal

Explore whether odh should expose a compact reliability/freshness score on curated live-data outputs, built from signals the CLI already knows: source, timestamp, freshness filters, diagnostics verdicts, stale-row warnings, request limits, and unsupported-capability caveats.

Scope

• Start with EV availability, parking forecasts, traffic events, A22 status, Tourism events, and GTFS realtime annotations.
• Define whether scores should be machine fields, human labels, or docs-only guidance.
• Preserve explicit warnings; do not hide caveats behind a single number.
• Avoid broad claims that exceed returned upstream metadata.

Done when

• Proposed scoring dimensions and JSON fields are documented.
• At least two real command outputs are mapped to the proposed labels.
• Decision is clear: implement, keep as docs/eval guidance, or reject.