[segran2]

An Easee current-setting readback can remain at 15 A while the actual pilot and circuit allocation allow 13 A. Treating the setting as the pilot makes a real charging limit look unexplained. This adds independently confirmed pilot evidence for srcfl/ftw#1874.

Change

• Expose pilot_a, pilot_observed_at, pilot_confirmed_at_ms and dynamic_limit_a separately.
• Refresh an observation's confirmation only when that REST/SignalR observation is accepted. Reading other observations does not refresh it.
• Keep unchanged old source timestamps usable when freshly confirmed, while rejecting missing, expired or future evidence before pilot/allocation values can explain a limit.
• Preserve fix(easee_cloud): report Easee's load balancing below FTW's order (1.4.1) #194's command, ordering, allocation and safety behavior.
• Propose easee_cloud 1.5.0 for the added telemetry; regenerate catalog metadata and add a changelog entry.

Dependency

Stacked on #194 at 34347fb92b08474b52e6240b28e78498110ba580, targeting easee-allocated-limit. This extends that work without rewriting or replacing it. Paired Core extension: srcfl/ftw#1905 (stacked on srcfl/ftw#1537). After driver integration, FTW still needs a separate pin/snapshot update to the merged driver commit; this PR does not publish a signed artifact.

Validation

• Exact PR tree: make test-driver ID=easee_cloud: 44 passed, 15 skipped.
• Exact PR tree: make check: 4,992 passed, 936 skipped; generated metadata and whitespace checks passed.
• Added harness covers separate 13 A pilot / 15 A setting, constant old source timestamp freshly confirmed by REST, missing observations not refreshing the pilot, zero pilot, no invented limit and future timestamps.

On 27 October 2026 the paired logic ran locally on FTW v0.157.2-beta.1+local.2 with an Easee cloud charger and Audi e-tron. The live driver was the same logic with unpublished 1.4.1 metadata; this PR's 1.5.0 is a version/catalog change, not a second hardware-tested binary.

1. With the car allowed to charge: 15 A request, 15 A pilot and approximately 10.46 kW; Following FTW.
2. Natural charger allocation: request/setting 15 A, pilot/allocation 13 A, approximately 8.93 kW. Six consecutive settled samples over about 54 seconds showed Core load_balancer_limit/info, and the actual EV sheet displayed “Limited by the charger’s load balancing” without a red warning.
3. Releasing the temporary hold returned to plan, 0 A pilot and 0 W; no persistent goal or protection limit was changed.

This is one-site evidence. Charger model/firmware identifiers were not captured, and no claim is made about the exact internal allocation algorithm or which household load triggered it. Communication-loss/recovery and release-of-load-balancing transitions were not hardware-tested here; freshness/order regressions are software evidence. Keep draft pending dependency integration, CI and remaining device identification/review. No site configuration, credentials, raw household history or device identifiers are committed.