feat(plugins): add read-only multi-instance E64 sensor

[MaxRink]

Summary

Add an opt-in E64 sensor plugin that reads grinder telemetry through the existing host-owned WebSocket transport, with independent same-model instances and no grinder writes.

• Keep one registration, socket, request counter, pending map, timer, and connection epoch per configured instance.
• Expose only readState, readConfig, readMachineInfo, and readLogMessages, with exact request/ref correlation and complete typed object publications.
• Validate configuration and secure tokens before opening sockets, isolate one instance's failure, and preserve existing primary/auxiliary scale connections.

Linked Issue

Related #854. Depends on the encoded opaque-ID API fix #858. The merged #847 Bengle fix and separate #747/#748 MOTTO80 work are outside this plugin.

The new discussion issue is awaiting maintainer triage. This PR remains a draft while maintainers discuss the proposal; opening the issue does not satisfy the accepted-issue gate or imply approval of the proposed contract.

Verification

• Combined Linux Flutter gate for the current publication stack: 4,315 passed, 1 skipped, 0 failed; analyzer clean (48.0s). Source was unchanged during the gate.

• Simulated two-fixture E64 runtime passed REST info and all four reads for both instances, independent WebSocket snapshots, and left fixture B responsive after fixture A disconnected.

• Simulated two-fixture E64 runtime passed REST info and all four reads for both instances, independent WebSocket snapshots, and left fixture B responsive after fixture A disconnected.

Impact

This adds an opt-in telemetry-only sensor path. It sends no motor, calibration, brew-event, or GBS writes, and it does not alter the existing scale API or inventory contract. The prerequisite sensor-selection fix is included in this branch and must land first through #858.

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]

0.9.0 direction: #889 is now the contract gate for connected grinder semantics.

This draft is useful evidence that the existing plugin network transport can support independent E64 instances, correlation, reconnect isolation and typed telemetry. I am happy for that work to remain the read-only proof, but I do not want the Sensor registration/payload here to become the permanent grinder-facing API.

After the generic Grinder domain lands, the intended follow-up is to adapt E64 onto type: grinder so it consumes the same transport-independent Grinder controller/API as a BLE-backed grinder. E64-only config, machine information and logs should remain plugin-specific. No need to add motor/write behavior merely to satisfy that migration; read-only Grinder telemetry is a valid first consumer.

Please treat the current PR as runtime/transport reference work pending #889 rather than as a competing Grinder API design.