bug: Disk widget write rate is ~2.5× high (5 s linux2rest sample ÷ 2 s poll)

### Bug description

The system-tray disk widget (`W: … MB/s`) reports **~5.0–5.1 MB/s** during a sustained ~16 Mbps H264 MCAP recording. Block-layer writes, process `write_bytes`, and MCAP file growth over 5 minutes are all **~2.1 MB/s**. There is no extra 3 MB/s writer.

`GET /system-information/system/disk` (linux2rest) only returns capacity. BlueOS invents `write_rate_Bps` in `updateSystemDisk`:

- Polls every **2 s** (`fetchSubscribedSystemInformationTask`).
- linux2rest Sampler only refreshes `available_space_B` every **5 s**.
- On a non-zero capacity jump, rate = `disk_delta / timeDelta` where `timeDelta` is the **poll** interval, not the Sampler window.
- On a zero delta (stale snapshot), the **previous inflated rate is kept**.

So ~10.5 MB written in 5 s is shown as `10.5e6 / 2 / 1024² ≈ 5.0–5.1 MB/s` and stays there.

Network already divides linux2rest per-sample deltas by 5 s (`networkProbeRateBps` / `LINUX2REST_SYSTEM_SAMPLE_INTERVAL_S`). Disk does not.

### Steps to reproduce

1. On BlueOS, start a ~16 Mbps video recording to MCAP (or any ~2 MB/s sequential writer).
2. Watch the disk tray widget: **W: 5.0–5.1 MB/s**.
3. On the vehicle, over ≥5 minutes:

```text
MCAP file growth ≈ 2.02 MB/s
mmcblk0 writes ≈ 2.09 MB/s
```

4. Expected: widget ≈ **2.1 MB/s**.

### Primary pain point(s)

The widget cannot be used to judge SD-card load or recording cost. It looks like the disk is writing 2.5× what it actually is, which also made a 42 GB / 8 h MCAP look inconsistent with “5 MB/s”.

### Additional context

- **Must land together with** https://github.com/patrickelectric/linux2rest/issues/38: additive `read_B` / `written_B` (and totals) on `/system/disk`, same meaning as `received_B` / `transmitted_B`. Do not break existing capacity fields.
- Frontend: if `written_B` is present, `write_rate_Bps = written_B / LINUX2REST_SYSTEM_SAMPLE_INTERVAL_S`. If missing (old linux2rest), still divide capacity delta by **5 s**, not the 2 s poll, and do not freeze a rate computed with the wrong `dt`.
- Overlay `/` inside `blueos-core` does not map to `/proc/diskstats`; linux2rest should copy backing-device I/O onto the `/` entry so this widget (which keys on `mount_point === '/'`) sees it.
- Also match previous disks by `mount_point`, not `name` (many bind mounts share `name: /dev/root`).

### Prerequisites

- [x] I have checked to make sure that a similar request has not already been filed or fixed.