fix(virtio): release zone scmi clocks/power domains on zone shutdown

[agicy]

Summary

This PR makes virtio-scmi resource lifecycle kernel-owned. Previously, a zone that was shut down left every clock it had enabled and every power domain it had powered on through SCMI in that state (the daemon only translated requests and never released anything). On the RK3588 multi-zone setup, restarting the Android zone right after zone shutdown crashed: the passthrough VOP kept running with stale DMA/interrupt state into the next boot (vop2_isr: couldn't enable clocks -> rk_iommu_irq reading unclocked registers -> Asynchronous SError -> kernel panic).

Now hvisor.ko accounts, per (zone, resource), how many times a zone enabled a clock or powered on a domain through the SCMI ioctls, and releases exactly that zone's contribution:

• on HVISOR_ZONE_SHUTDOWN (after the zone is destroyed), and
• on HVISOR_ZONE_START (before the new instance boots) - a zone can only be started when no instance of it is alive, so any recorded state belongs to a dead instance. This makes every death path (explicit shutdown, crash, guest self-halt, daemon restart) converge on clean hardware for the next boot.

Release order is clocks first (stops scanout/DMA, removing the source of stale interrupts), then power domains (the actual hardware reset).

Motivation

zone shutdown killed the guest but left the passthrough hardware running: clk_summary showed VOP/DSI clocks still enabled (owner hvisor_virtio_device) and pm_genpd showed vop/gpu still on after shutdown. The next boot of the zone therefore took a stale interrupt storm before its drivers had enabled clocks/power, causing an asynchronous SError panic. The daemon cannot fix this by itself: it does not see zone lifecycle events and its state is lost on restart, while the kernel driver executes the clk/pd operations and sees start/shutdown synchronously.

Per-zone accounting also makes the release safe for shared resources: a clock or domain shared with another zone or with the root OS is only released by the zone that actually enabled/powered it on.

Verification

• zone shutdown on the RK3588 board: dmesg shows hvisor.ko: released scmi resources of zone 2; clk_summary shows the VOP/GPU clocks disabled and pm_genpd shows vop = off-0, gpu = off-0. The USB domain correctly stays on, held by the root OS's own usbdrd3_1 device - evidence that only the shut-down zone's contribution was released.
• zone start after shutdown: second boot is clean, no SError panic, display and USB keyboard functional.
• Build: make all ARCH=arm64 LOG=LOG_INFO KDIR=... (kernel 6.1 SDK) for both tools/hvisor and driver/hvisor.ko.

Not directly exercised yet: a guest that halts/crashes without an explicit zone shutdown followed by a plain zone start (covered by the start-hook design but worth a dedicated test), and a scenario where two zones share the same clock/domain.

Risks and Limitations

• hvisor_scmi_clock_args/hvisor_scmi_power_args gain a zone_id field (shared header); daemon, tool and driver must be rebuilt from the same tree.
• Per-zone accounting tables are capped at SCMI_MAX_ZONES (16); requests from other zones are ignored for accounting beyond that.
• The start-hook invariant ("a zone can only be started when no instance is alive") is relied upon to clean up after zones that died without an explicit shutdown; it holds for the current hvisor zone model.
• Tested on RK3588 (sysoul_x3300) only.