feat(bengle): fill in the real EndOfShotWeight and ScaleTare registers

[ChampionDesigns]

Stacked PR — B-4 of 10. Builds on #461 (feat/bengle-0xa013-scale). Until that merges this PR's diff includes its commits; please review/merge in order B-1 → B-10.

The story

Almost all of the stop-at-weight surface is already upstream: the BengleInterface methods, the
mixin's cache and stream, MockBengle, the ShotSequencer bypass that defers the final stop to the
machine, BengleSawBridge, the machineHasAutonomousSAW flag on the shot state, and the
stopAtWeight capability string. What is missing is the register. BengleScaleMmr.stopAtWeightTarget
was declared with address 0x00000000 and a guessed scale, and the setter checked for that address
and quietly returned. So the app cached your target weight, showed it back to you, told the shot
sequencer the machine would handle the stop, and never told the machine what the target was. Tare had
the same shape: tareIntegratedScale() was a logged no-op waiting for a firmware slot that in fact
already existed. This PR fills in both registers with the firmware's truth and turns two stubs into
two writes.

Summary

• Problem: stopAtWeightTarget was stubbed at address 0x00000000 with a guessed x10 decigram
  scale and a 500 g clamp, so setStopAtWeightTarget never reached the wire. tareIntegratedScale()
  was a logged no-op.
• Why it matters: the app already tells the shot sequencer to stand down and let the machine stop
  the shot (machineHasAutonomousSAW), so a target that never arrives at the firmware means nobody
  is stopping on weight. The value was cached and streamed back to the UI, which made it look like it
  had been set.
• What changed: stopAtWeightTarget is now the firmware's EndOfShotWeight register
  (0x00803864, RWD), scaled x100, so centigrams on the wire, 0 disables, maximum 10000 g. A new
  scaleTare register (0x0080388C, RWT) is a write-trigger: the value is ignored, we send 1 to
  match de1plus, and the firmware performs an immediate tare. getStopAtWeightTarget now reads
  the register back and hydrates the stream cache.
• What did NOT change (scope boundary): no new REST endpoint and no spec path change. The generic
  PUT /api/v1/scale/tare already reaches the new trigger through the existing
  ScaleController -> BengleVirtualScale.tare() -> tareIntegratedScale() chain. The weight
  pipeline is untouched: the firmware serves CurrW - LastTARE, so 0xA013 weight arrives already
  net of the new zero and nothing downstream needs to know a tare happened.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore / infra
• Plugin (DYE2 or bundled skin)

Arguably a bug fix, since the shipped surface silently did nothing. I have called it a feature because
the surface it completes was never released as working.

Scope (select all touched areas)

• BLE transport / device comms
• REST API / handlers (capability string and spec description only; no new path)
• WebSocket API
• Machine state / shot logic
• Scale / weight / flow
• Profiles / beans / grinders / workflows
• WebUI skins
• Plugins / JS runtime
• UI / Flutter widgets
• Storage / Drift database
• CI / build / infra
• Docs / specs

Linked Issues

• Closes # N/A - no tracking issue
• Related # N/A

Root Cause (if bug fix)

N/A - this completes a deliberately stubbed surface rather than fixing a regression. The stub was
honest about itself (the address was 0x00000000 and the code path logged that it was awaiting
firmware); what it lacked was any test that would fail once the firmware slot existed and the app
still was not using it.

Regression Test Plan (if bug fix or refactor)

• Coverage level that should have caught this:
  • Unit test
  • Integration test (mock transport edge)
  • End-to-end test (simulate=1 + curl/websocat)
  • Existing coverage already sufficient
• Target test or file: test/models/device/bengle_saw_test.dart (rewritten from a stub-pinning
  group to byte-exact wire assertions), test/unit/models/device/impl/de1/unified_de1/ integrated_scale_capability_test.dart (the tare case), test/controllers/ de1_state_manager_shot_state_test.dart, test/services/webserver/de1handler_cup_warmer_test.dart.
• Scenario the test should lock in: the wire bytes, not the cache. A setStopAtWeightTarget(2.3)
  must put 230 (centigrams) at address 0x00803864, not 229 and not the cached double; 0.0
  must disable; out-of-range values must clamp at 0 and 10000 g; the read-back must hydrate the
  stream. A tare must emit exactly one MMR write (length 4, address 0x80388C, payload 1,
  little-endian). The state-manager tests lock machineHasAutonomousSAW == true on every Bengle shot
  state frame including the idle re-seed, and false on a plain DE1. The handler test locks
  stopAtWeight into /machine/capabilities for a Bengle and out of it for a DE1.

Documentation Obligations (required)

• API spec updated: assets/api/rest_v1.yml - the capabilities path description now lists the
  four live capability identifiers and states the stopAtWeight / targetYield semantics. The
  schema already carried them.
• API docs updated: doc/Api.md - unchanged by design. PUT /api/v1/scale/tare is the same
  endpoint with the same contract; it simply now does something on a Bengle.
• Plugin docs updated
• Skin docs updated
• Profile docs updated
• Device docs updated
• Other: the bengle-integrated-scale end-to-end scenario is refreshed to the autonomous-SAW
  reality (the workflow's target yield goes to the SAW register, the app defers the final stop,
  and the shot's stopReason is machineEnded).

Security Impact (required)

• New or changed REST endpoints? No
• New or changed WebSocket topics? No
• New or changed network calls? No
• BLE/USB surface changed? Yes - two MMR registers that were never written are now written. Both
  are Bengle-only addresses reached only through BengleInterface, so a plain DE1 cannot be sent
  either write. The tare is a write-trigger with an ignored value.
• File system access changed? No
• Plugin sandbox boundary changed? No

User-Visible Changes

Stop-at-weight actually stops the shot at the weight you asked for, because the machine now knows the
target. Tare actually tares. stopAtWeight appears in /api/v1/machine/capabilities on a Bengle
(and did not before, since the capability string was already listed but the feature behind it was
inert). The advertised SAW range widens from 0..500 g to 0..10000 g, matching the firmware.

Verification

Local gates (run before pushing)

• flutter analyze - clean (No issues found!)
• flutter test - 2113 tests pass at this branch head (B-3 was 2104; +9 from this branch's
  own tests)
• (cd packages/dye2-plugin && npm run build) - plugin builds

Manual verification (if applicable)

• OS / platform tested: Linux (analyzer, full test suite).
• Simulated devices? (simulate=1): No
• Real hardware? (DE1/Bengle/scale): No, not by me on this branch.
• What you personally verified and how: the local gate set, and every register field in this diff
  read back against the firmware register table and the bengle_hw_v1.yml contract file added in
  B-1. Both new registers are registered with the contract checker, so a firmware-side change to
  either address, length or multiplier now fails CI here.
• Edge cases checked (by test): the rounding boundary (2.3 * 100 is 229.999... in IEEE-754, so
  toInt() would write 229; the shared writeMmrScaled rounds, which is B-1's fix and is what
  makes this write correct); 0.0 as a disable rather than a target; clamping at both ends.
• What you did not verify: I did not pull a shot on hardware with this branch and watch the
  machine stop at a target weight. That is the obvious end-to-end test and it has not been run
  against this slice. The byte-level assertions say the right bytes go to the right address with the
  right scaling, which is a strong claim about the wire and a weaker one about the outcome. I also
  did not verify the read-back path against firmware that has a persisted non-zero target.

Evidence

• Test output (2113 pass; bengle_saw_test is now byte-exact rather than stub-pinning)
• Log snippets
• Screenshot / recording (UI changes)
• curl / websocat output (API changes)

Compatibility & Migration

• Backward compatible? Yes
• Config / env changes needed? No
• Database migration needed? No

MockBengle's clamp moves from 500 g to 10000 g to match. A client that was setting a SAW target and
seeing it echoed back will now find the machine honouring it, which is the point.

Deliberate choices worth your review

1. The firmware does not clamp its Bengle registers, so the app is the only guard.
   the firmware write path divides by the multiplier and stores. A client-side clamp to 0..10000 g plus the raw
   maximum on the enum is all that stands between a bad value and the register. That is a real
   asymmetry with the DE1 registers and worth knowing about.
2. The registers live on BengleScaleMmr, not BengleMmr. The rule is that a capability owns
   the registers it writes. The mixin is part of the unified_de1 library, and importing the Bengle
   subclass's bengle_mmr.dart into it would invert the import layering. This is a deliberate
   divergence from the original design sketch, and it is why the tare register is declared next to
   the scale code rather than with the other Bengle registers.
3. A tare is confirmed by watching the weight, never by the 0xA013 Flags bit. Bit 0 of the
   Flags byte is a LastTARE value proxy at best, and older firmware hardcodes it to 0. Reads of
   ScaleTare return 0 by design; it is a trigger, not a value.
4. getStopAtWeightTarget now hits the wire, but production still uses write-precedence.
   BengleSawBridge's connect-time re-apply remains the source of truth. The read-back exists so the
   cache can be hydrated from the wire and so the value can be checked, not so that the firmware
   becomes the authority mid-session.

Risks & Mitigations

• Risk: a client that previously sent a SAW target above 500 g and had it silently clamped will
  now have it honoured by the machine.
  • Mitigation: the old clamp was a guess against a stubbed register that never reached the wire,
    so nothing was ever honoured. The new bound is the firmware's own maximum. This is not really a
    behaviour change for anyone; it is the feature starting to work.
• Risk: the scaled write rounds, and somebody later "fixes" it back to truncation.
  • Mitigation: B-1 test-pins both directions of the scaled-write split (setSteamFlow(2.3) must
    land 229, a capability write of 2.3 at x100 must land 230), and bengle_saw_test asserts
    the 230 case again at the SAW call site.