perf(coordinator): parallelize RCI fetches with bounded, staged concurrency

[ABovsh]

Summary

Replace the sequential fetch loop in KeeneticCoordinator._async_update_data with bounded, staged parallelism. This shortens each coordinator tick on mid-range Keenetic hardware and, on slower routers or busier networks, helps the coordinator stay within FAST_SCAN_INTERVAL instead of overrunning it (which causes Home Assistant to silently skip ticks and roughly double the observed update cadence).

This is a self-contained change: only the body of _async_update_data is touched. No public API, no entity descriptions, no other files.

What this PR does

The fetches are split into three dependency stages, each internally parallel, with a shared asyncio.Semaphore(4) capping concurrent in-flight RCI calls:

Stage	Calls	Depends on
1	system_info, current_version, available_version, interfaces, clients, mesh_nodes, client_stats, host_policies, ndns_info, usb_storage, interface_stats, ping_check_status	—

• Hardware Protection: Concurrency is bounded to 4 because Keenetic's RCI is a single HTTP surface served by a modest router CPU. Firing 15+ requests fully in parallel risks 503s or auth contention on lower-end hardware.
• Fault Tolerance: All asyncio.gather calls use return_exceptions=True, and a small _ok() helper normalizes any failed fetch into a safe default of the correct shape. As a side effect, a single flaky endpoint no longer kills the entire update tick — that data point is simply absent for one cycle, and the next tick retries it.
• Logic Maintained: WAN enrichment, role labeling, throughput-delta calculation, new-client detection, and the final return dict are byte-for-byte unchanged.