feat(plugins): open per-device settings from device management

[MaxRink]

Summary

Implement a generic native device-settings entry that opens a validated plugin-owned settings endpoint using the stable public device identity.

• Associate an optional settings endpoint with a registered driver and validate it against the loaded manifest, API permission, and declared HTTP endpoints.
• Open the endpoint in the existing in-app browser path with encoded public deviceId and optional name parameters.
• Keep the plugin endpoint and existing KV store as the sole persistence authority; do not add a native duplicate store or infer endpoints from device-ID prefixes.

This branch builds on #844 metadata. It keeps the host's existing one-binding limit and can be reviewed independently of multiple-scale support. The Skale driver in #846 declares its plugin-owned settings endpoint; this separate generic PR adds the native entry point.

Linked Issue

Related #855 and #716. Depends on #844; #846 declares its device-settings endpoint.

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.

• Combined simulated runtime checks passed for the current stack; no production fixes were needed during runtime validation.

Impact

Each applicable plugin device opens its own validated settings authority. Plugin-global settings remain separate, and unavailable/retired instances cannot open settings. No public inventory field is added; the authoritative manifest schema and plugin/device documentation describe the driver endpoint contract.

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]

Maintainer direction for 0.9.0: this is P0 generic driver-runtime v2 work. #855 is accepted; see execution tracker #890.

Please make the settings-entry contract device-type agnostic rather than Scale/Sensor-specific. A validated driver-declared endpoint should also work for the Grinder domain in #889. Keep deviceId as the required runtime identity, deviceName display-only, and the plugin endpoint + existing KV store as the sole persistence authority. No connection-role semantics or native mirror store.