feat(api): expose charging evidence to clients and Ask why

[frahlg]

Charging questions currently depend on text reports and several reads. Add GET /api/loadpoints/{id}/evidence and the read-only get_charging_evidence Ask why tool, using the same loadpoint view as the existing UI. Calling the tool without an ID lists up to 32 loadpoint IDs.

The versioned response includes saved goals, plan windows and freshness, Core's last commanded watts and reason, and a separate charger observation. The observation distinguishes telemetry receipt time from source power time. Missing, offline, malformed or stale power becomes null; a cached zero cannot imply that charging stopped. A failed replan retains diagnostics while marking the plan outdated and omitting its old windows.

The endpoint uses the existing Read tier. It adds no control authority or MCP service. Core's commanded watts remain distinct from a device acknowledgement, and observed power does not prove which command caused it. Reads span separate state snapshots, with collection bounds included in the response. The ordinary loadpoint response and UI remain unchanged.

Validation:

• PATH=/opt/homebrew/bin:$PATH make verify passed: Go tests, vet/build, deployment and release fixtures, and bundled Energyplan checks.
• Focused charging/Ask why tests and race checks passed, including stale cloud power, unknown connection, planned waiting, failed replan, HTTP/tool/UI agreement and a full Ask why tool round trip through a local mock provider.
• Brand and planning-document checks passed.
• GitHub CI passed. The first Go run hit GitHub's API rate limit in the existing storage downgrade test; the failed job passed on retry with the same commit.

No live model, physical charger or customer installation was used. The next validation step is reading evidence from a candidate on a test box. Related model work in #1292 touches different files; this change does not depend on it. Linux packaging remains in #1336.