feat(scale): show connected Skale firmware revision

[MaxRink]

Summary

Read the connected Skale firmware revision from the standard Device Information Service and show the opaque value in Devices and GET /api/v1/scale/info. Metadata belongs to the current connection and clears on disconnect.

Linked Issue

Fixes #714

Verification

• Full Flutter 3.44.2 Linux suite: 4,170 passed, 1 skipped, 0 failed.
• dart format lib test: no changes; flutter analyze: no issues.
• Focused fake-transport and handler tests cover metadata clearing, valid/unknown values, and REST/WS inventory exclusion.
• Simulated integration of the native Skale series exercised the metadata endpoint through sb-dev, including hot reload. The companion USB branch also verified settings persistence across cold restart.
• Physical Skale hardware was not retested for this revision.

Impact

Firmware metadata uses the narrow DeviceInformationCapable capability; other scales do not need no-op metadata getters. Device inventory REST/WS contracts remain unchanged. No firmware update or DFU behavior is added. API and device documentation are updated.

Contributor Responsibility

AI-assisted development is allowed. The submitter remains responsible for the submitted work.

• I have reviewed and understand all changes in this PR and take responsibility for their correctness, security, behavior, licensing, and provenance, including any AI-assisted or AI-generated work.

[tadelv]

I think the API boundary here should be changed before merge.

GET /api/v1/devices is an inventory/discovery surface: it can contain connected devices, currently available devices, and remembered devices that are no longer present. Adding connection-scoped deviceInfo to those inventory entries makes the resource ambiguous, because the enclosing device can persist while the metadata only exists for an active connection.

We already have a clearer precedent with GET /api/v1/machine/info, which represents information about the currently connected machine. I would prefer the scale side to follow the same model:

• do not add deviceInfo to /api/v1/devices or /ws/v1/devices;
• add GET /api/v1/scale/info for information obtained from the currently connected scale;
• keep firmwareVersion opaque and optional;
• let #743 extend the same ScaleInfo contract with nullable/optional batteryLevel;
• if live scale-info updates are eventually needed, prefer a dedicated /ws/v1/scale/info surface rather than causing the device-inventory stream to change for metadata refreshes. I would not add that WebSocket until there is a concrete need.

This keeps a useful API distinction going forward: /api/v1/devices answers what devices exist and their connection state; role-specific /machine/info and /scale/info endpoints answer what Decaid has learned from the currently connected device. That also keeps this generic across future scale implementations without coupling the public API to Skale.

[tadelv]

The revised API boundary is now aligned with the requested design: connected scale metadata lives under /api/v1/scale/info, while device inventory remains inventory-only. I still see two code/docs issues called out inline, plus the current head fails the repository's Dart format check, which is a hard pre-PR/verification gate in AGENTS.md and prevents analyze/tests from running in CI. Please run dart format lib test, push the formatter output, and address the inline items.

[tadelv]

The two previous blockers are resolved. One cleanup remains from the abandoned inventory-metadata implementation: please revert the unused multi-subscription bookkeeping in DevicesStateAggregator back to the original single connection-state subscription shape. With inventory no longer subscribing to metadata, this refactor has no purpose and conflicts with the repository guidance to avoid adjacent refactors that the task does not require.

[tadelv]

This List<StreamSubscription> shape is leftover scaffolding from when the PR was going to subscribe device inventory to metadata. The corrected design no longer does that, so every device still has exactly one connection-state subscription. Please revert this map and the associated loops to the original (Device, StreamSubscription) bookkeeping rather than carrying an unrelated complexity increase into #742.

[MaxRink]

Restored the original (Device, StreamSubscription) bookkeeping in f860b0e, including the single cancellation calls. devices_handler.dart now has no diff against the base implementation. Applied the same cleanup to #743 and #745.

[tadelv]

The API boundary and the previously requested cleanup are now in the right shape. I still want two things corrected before merge:

1. Please remove the broad no-op ScaleInfo? get scaleInfo => null overrides from every non-Skale scale implementation/test double. Scale already provides that default, so these edits add churn across unrelated device implementations without changing behavior. This is exactly the kind of adjacent change AGENTS.md asks us to avoid; only implementations that actually provide scale info should override it.
2. Please drop the remaining unrelated diff while doing that (tare/timer warning additions in scale_handler.dart and the newline-only websocket_v1.yml change). They are not needed for #714.

Also, please verify the result against current main before considering this ready. #820 has now merged the host-owned BLE/plugin-driver checkpoint, while this branch's local/full-suite evidence predates that merge and the current PR workflow is still action_required with no jobs. A rebase plus the relevant Scale/PluginScale/API tests (or a green merge-result CI run) is enough; no extra hardware testing is required for this review.

I do not think #742 itself needs to be held for the generic-driver work: /api/v1/scale/info is a generic host/domain surface and the Skale firmware read is narrowly scoped. But please keep the new metadata abstraction minimal here; richer plugin/device capabilities should continue to be defined through #809 rather than expanded from this Skale-specific PR.