Handle missing time_since_update in diskio data

[trezit]

Fixes #57.

Glances v4 only adds time_since_update (and the *_rate_per_sec fields) to a plugin's stats once a previous sample exists: _manage_rate returns the raw stats when stat_previous is None. The first diskio sample after the Glances server starts therefore lacks the key, and get_ha_sensor_data() raises KeyError: 'time_since_update'.

In Home Assistant, get_api() does not catch this KeyError during setup. When the host reboots and Glances and Home Assistant start together, the config entry ends in a setup error and is never retried: every Glances sensor stays unavailable until the integration is reloaded by hand. Seen with Glances 4.5.7, glances_api 0.10.0 and Home Assistant 2026.9.3 (Home Assistant's first call came 6 s after Glances started).

Change: when time_since_update is missing (or 0), keep the disk with read/write set to None, as the network sensors already do for v4. The disk has to stay in the data, because Home Assistant creates the diskio entities from the keys present in the first update. They are unavailable for that single update and get values on the next one.

A test covers the first-sample payload (values from a Glances 4.5.7 server). It fails with the KeyError without the fix. pytest, ruff check and mypy pass.

🤖 Generated with Claude Code

[FirebladeBMW]

Adding some field evidence from a production install, because the impact of
this is worse than a log line:

Environment: Home Assistant 2026.10.0b0, Glances 4.4.1 on the monitored host
(Debian 13 / Proxmox VE), v4 API.

Reproduction: Reboot the monitored host. Glances restarts fresh, and its
_manage_rate decorator skips rate computation on the very first update
("if stats_previous is None: return stats" in
glances/plugins/plugin/model.py), so the first diskio payload has no
"time_since_update" key. If the HA config entry runs get_ha_sensor_data()
during that window, disk["time_since_update"] raises KeyError.

Why this is severe: During config-entry setup this is not a
ConfigEntryNotReady, so Home Assistant marks the entry as setup_error and
does not retry. All Glances sensors then stay unavailable indefinitely -
every host reboot breaks the integration until someone reloads it manually
from the UI. (Somewhat related: home-assistant/core#144455 was closed as
stale without a fix.)

The disk.get() fallback with None rates in this PR matches exactly what a
first sample can honestly report and would turn the crash into a normal
rate-less reading. On our instance every subsequent sample we captured
carries the key - only the first one after a Glances start is missing it.

Happy to test a branch or wheel against our setup.