feat(api): add plan-to-execution support diagnostics

[frahlg]

Why

A v1.15 support bundle from a passive-arbitrage site showed a live target of +33.659 W, but it could not prove which accepted plan or forecast inputs reached control. It also exposed raw host, location, network, and device identifiers.

The small target itself matches the existing remaining-energy calculation: a 100 Wh slot had already met its budget, the battery drifted by about -26 W, and 64.08 seconds remained. That explains the target shape, but it does not prove that the accepted plan was correct.

What changed

• Add plan-execution.json to the help bundle.
• Record runtime mode and build identity, the accepted plan ID, current and future typed slots, forecast values and source times, and the exact control slot.
• Join plan and control only when decision ID, slot start, slot end, and planned energy all match.
• Include bounded targets, clamps, command results, driver health, measurements, and explicit reasons when a link cannot be proved.
• Alias device and loadpoint names. Redact credentials, hostnames, URLs, network addresses, coordinates, serials, and opaque config/result fields before export.
• Apply file, row, field, and byte limits at the data source. Mark partial snapshots instead of drawing conclusions from incomplete fleet totals.
• Omit raw telemetry CSV because the current store cannot prove its producer. Typed Core measurements remain in the diagnostic file.
• Add a synthetic regression for the field report's +33.659 W passive-arbitrage target.

Limits

Driver command result v1 does not carry a plan decision ID. The bundle says that this join is unavailable; it does not infer causation from timestamps.

This PR does not close #885, #766, or #822.

Stack and merge order

This draft is stacked on #926 and #922 so its diff contains only support diagnostics. Do not merge it before those PRs. #769 keeps its feature work and must rebase after the agreed safety/support order; #887 and #888 follow #769.

Checks

• Final-head focused API, state, and support-report tests
• make verify on the reviewed stack: 167 optimizer tests, all Go packages, external optimizer checks, Compose migration, boundaries, vet, and build
• Race tests for API, state, telemetry, planner, control, and Core
• Adversarial privacy tests for credentials, DNS/endpoint paths, IDs, coordinates, oversized fields, and partial snapshots