New backend: whole-machine power from the battery discharge rate on laptops

Is your feature request related to a problem? Please describe.

CodeCarbon's measured power sources (RAPL on Linux, EMI on Windows — #1263, PowerMetrics on macOS) only cover the CPU package (and optionally DRAM). Everything else — screen, storage, Wi-Fi, fans, VRM losses, dGPU idle rails — is either estimated or missing, so total machine consumption is underestimated. The RAPL psys (platform) domain would help, but it is rarely exposed: on a Windows 11 laptop (Intel Core Ultra 7 265H), EMI only enumerates PKG/DRAM/PP0/PP1, with no platform channel.

Laptops already have a built-in whole-machine power meter: the battery fuel gauge. While discharging, the battery reports the true power drawn by the entire machine.

Describe the solution you'd like

A new opt-in backend that reads the battery discharge rate:

• Windows: GetSystemPowerStatus for AC/battery state, and the WMI class root\wmi:BatteryStatus (DischargeRate, in mW) for the actual draw. No admin rights needed.
• Linux: /sys/class/power_supply/BAT*/power_now (µW), or current_now × voltage_now where power_now is absent.
• macOS: ioreg -rn AppleSmartBattery (Amperage × Voltage).

Behavior:

• Only valid while unplugged and discharging — the backend must check AC state and report "not available" (falling back to the existing chain) when on AC power, and handle the state changing mid-run (plug/unplug events should invalidate or segment the measurement).
• Sampling caveat: fuel gauges update slowly (~1 s or worse) and readings are noisy; averaging over the measurement interval is required.
• Positioning: either a distinct tracking mode for whole-machine measurement, or a validation/calibration tool for the estimated components. It should probably not silently replace the CPU backend, since its scope (whole machine) differs from every other power source.

Describe alternatives you've considered

• RAPL psys domain where available (already supported on Linux via rapl_prefer_psys) — the cleanest source, but rarely exposed, and never seen through Windows EMI so far.
• External smart plugs / wall meters — accurate and works for desktops, but requires hardware and manual integration.
• Dedicated metering hardware via EMI (e.g. Surface Book battery metering on Windows 10) — already picked up transparently by the EMI backend when present, but limited to rare devices.
• Status quo: keep estimating non-CPU components.

Additional context

Follow-up idea from the discussion around #1263 / #457. Mozilla's power profiler documents similar trade-offs when they moved off Intel Power Gadget. Desktops have no battery, so this backend is inherently laptop-only, and measurements are only meaningful for on-battery workloads — which is also a common real-world usage scenario for the machines CodeCarbon runs on.

Start by reviewing the existing RAPL, EMI, and PowerMetrics backends and the discussions in #1263 and #457. Compare the Windows GetSystemPowerStatus/BatteryStatus, Linux power-supply, and macOS AppleSmartBattery entry points, then define the tracking or validation mode. Done means averaged on-battery discharge measurements, correct handling of plug/unplug transitions, and fallback when the battery source is unavailable.