feat: fence battery transport writes by controller epoch

[mgazza]

A controller handoff cannot rely on restart detection: GivEnergy requests can outlive client timeouts, and Hub schedules can be published from reconnect or periodic paths. Add an optional epoch-bound battery write gate at the actual GivEnergy and Hub transport sinks.

Closing the gate permanently rejects new writes and retries for that epoch. Outstanding attempts remain tracked across threads and event loops. Cancellation, timeout and ambiguous vendor responses cannot prove drain. Strict documented GivEnergy success responses can complete individual attempts; later success never clears earlier uncertainty. Hub broker acceptance remains uncertain because it does not revoke previously retained schedules. Independent EV, display and query traffic remains available.

No installation attaches the gate by default. This does not enable the provider selector, automatic backup or a production handoff. Durable backend coordination, target readiness and a physical Hub fence that invalidates old commands/schedules remain required. See docs/control-write-drain-gate.md for the full contract and provider-response inference.

Validation:

• Ten new tests exercise the actual decorated Cloud transport/retry loop and Hub sink, including concurrent closure, pending owner-loop futures, cancellation, late remote application, retained plan reconnect/republish and independent roles.
• Existing GivEnergy suite: 138/138 passed. Existing Gateway suite passed.
• Black, configured Ruff selectors and whitespace checks pass.
• GitNexus staged analysis: medium risk, six expected files, one affected Number_event to Control_gate_for flow.

Stacked on #5504. No production changes.