feat(scale): reserve a second scale for weighing the dose

[SongPaul]

Summary

What changed, and why?

• Baristas weigh the dose on one scale and the shot on another, and today the gateway holds exactly one scale so the second cannot be connected at all. This reserves a second scale by id for weighing the dose, and leaves the brewing path as it is.
• DosingScaleController is a new class with its own slot, connection subscription and snapshot stream. ScaleController is not modified, so tare-before-pour, stop-at-weight and shot recording are not on this diff.
• A dosingScaleId setting sits beside the existing preferredScaleId. The brewing path's exposure is a single exclusion in _runScalePhase: the reserved scale is filtered out of the list handed to _applyScalePolicy, and every other scale is accepted exactly as before. With no dosingScaleId set, _runScalePhase returns down the original path untouched.
• New endpoints beside the existing ones rather than a role parameter on them, so no request an existing skin already sends changes: ws/v1/scale/dosing/snapshot and PUT /api/v1/scale/dosing/tare are new; ws/v1/scale/snapshot and PUT /api/v1/scale/tare are unchanged.
• Device management gains a dosing-scale section with its own scan, and a scale reserved for dosing is no longer offered for brewing.
• Unavailable while a Bengle is connected. The integrated scale takes the brewing slot and external discovery is skipped for the duration, so re-entering discovery for a dosing scale alone would contradict a decision taken for that machine.
• Nothing in a shot reads it. A dose is weighed before extraction, so the dosing weight reaches the skin over its own socket and goes into the workflow as targetDoseWeight the way a typed dose does.

The design doc, including the alternatives rejected and why, is at doc/plans/archive/dosing-scale/2026-09-12-dosing-scale.md.

I understand role-keyed multi-scale is the better end state and is presumably where this lands eventually. If it lands, this should be removed rather than kept alongside it.

Linked Issue

Fixes #833

Verification

How did you verify the change? Include relevant tests and any manual or hardware testing.

• flutter analyze — no new issues; the only output is four pre-existing asset_directory_does_not_exist warnings for asset dirs a fresh checkout does not have.

• flutter test in full, against a baseline. My machine has a large number of environmental failures (core.autocrlf=true breaking byte-comparison tests, plus webui_support tests that bind port 3000, which was occupied), so rather than assert they were pre-existing I ran the same suite on origin/main in a second worktree and diffed the failure sets:

  	passed	failed
  origin/main (39c2156)	3769	384
  this branch	3790	384

  The two sets of 384 are identical — no test fails on this branch that does not also fail on main, and none of the 384 is in a file this branch touches. The 21 extra passes are the tests added here.

• test/controllers/dosing_scale_controller_test.dart — 16 tests in three groups: the brewing selection's handling of a reserved id (4), which scales brewing is actually offered (5), and the controller's own connect / tare / disconnect / generation behaviour (7). Two of them pin the no-dosing-scale case: "accepts every scale when no dosing scale is set" and "no dosing scale set leaves the list untouched".

• test/device_management_page_test.dart — 5 tests, including "a scale taken for dosing is not offered for brewing" and "with nothing reserved both scales are offered to brewing", which is the regression that matters.

• test/unit/controllers/settings_controller_test.dart — dosingScaleId round-trips through the settings service.

• On hardware, by the reporter, with two BLE scales connected at once: both snapshots arrive on their own sockets, taring one does not tare the other, and the brewing scale behaves as it did. Hot water and steam were exercised as well as the dosing readout. Two scales connected simultaneously is not an open question here.

• The first hardware attempt failed to connect the dosing scale while the same scale connected fine as a brew scale. Two differences from ScaleController were the cause: the dosing path claimed the scale before onConnect() returned and never verified the resulting state, and it ran outside _trackConnectionWork with no timeout, so a scan running concurrently on Android could stall it indefinitely. Both are fixed in de348cb5 and the connect now matches the brewing one.

Impact

Note any user-visible behavior, compatibility, migration, API/spec, documentation, or security impact. Write None if there is none.

• API: two new endpoints, ws/v1/scale/dosing/snapshot and PUT /api/v1/scale/dosing/tare. assets/api/rest_v1.yml and assets/api/websocket_v1.yml are updated in the same commits. No existing endpoint changes shape or behaviour.
• Behaviour: none unless a dosing scale is chosen. With dosingScaleId unset — which is every existing installation — the scale phase takes the same path it does today.
• Storage: one new SharedPreferences key, dosingScaleId. Nullable, no migration.
• Docs: doc/Api.md and doc/DeviceManagement.md updated; the design doc is archived under doc/plans/archive/dosing-scale/.
• Security: none.

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.

🤖 Generated with Claude Code

[SongPaul]

Design discussion for the shape of this — additive now vs waiting for role-keyed multi-scale — is at #835, since "should this exist in this form at all" is a maintainer call rather than a review comment. Happy to rework or withdraw this PR on the back of that conversation.

[SongPaul]

Superseded by #869, which reworks this around the generic model asked for in #833: one semantically special scale, auxiliary connections that are explicitly requested, runtime-only, never taken by primary auto-selection, and never read by the brewing path. No core dosing role, no persisted dosingScaleId, no dosing-specific endpoints, and the Bengle restriction is gone.

Closing in favour of that PR.