feat(web): add custom friendly names for drives

[Starosdev]

Feature Request

Environment

• Affected: Both
• Component: Backend / Frontend

---

Updated Scope

This issue is no longer about introducing a new FriendlyName field.

Scrutiny already has an existing persisted custom drive name field: Device.Label, exposed through the API and editable from the UI. That field is already used in notifications and Home Assistant MQTT discovery.

This issue now tracks making the existing custom label behavior consistent in dashboard-facing UI so that user-defined drive names are shown automatically when present, while still keeping the underlying device path visible for identification.

Existing Behavior Already Present

• Custom drive names are already persisted via the existing label field on Device
• The UI already allows setting and clearing that field from the device settings dialog
• Notifications already include the custom label when set
• MQTT discovery already uses the custom label when set

---

Actual Implementation Approach

Backend

• Reuse the existing Device.Label field
• Reuse the existing /api/device/:id/label endpoint
• No new database column or migration is required
• No notification payload changes are required

Frontend

• Prefer the existing custom label automatically on dashboard-facing views when set
• Keep the device path/model visible as secondary context instead of replacing identification entirely
• Leave the existing detail-page settings dialog in place for editing the label
• Preserve the existing global dashboard display preference for other title modes where appropriate

---

Acceptance Criteria

• Persisted custom drive name is available via the existing label field and API
• User can set and clear the custom drive name from the existing device settings UI
• Dashboard card title prefers the custom label when set and keeps the device path/model visible
• Dashboard drive filter and temperature-series labels prefer the custom label when set and keep fallback identification
• Notifications include the custom label when set
• Existing DeviceLabel / Label behavior is preserved; no new overlapping FriendlyName field is introduced

---

Notes

• The original issue body proposed a new FriendlyName field, but that would duplicate the current label concept and create overlapping naming semantics.
• The work for this issue is implemented by reusing the existing label flow rather than adding a second naming field.