[JanZachmann]

Closes #125

Summary

omnect-os moves from the scripted initramfs to omnect-os-init, an init written in Rust (omnect/meta-omnect#697). The new init writes a different factory-reset result and does not support reset mode 4; omnect/omnect-device-service#207 publishes this result as factory_reset feature version 4. This PR makes omnect-ui follow both changes. It also changes the probe of wifi-commissioning-service.

Factory reset result of feature version 4

• The factory-reset result types follow the format omnect-device-service publishes with feature version 4: status is a u32 with the codes success, invalid, error, configError and warning plus a catch-all, error and context are null when nothing went wrong, and the new data_wiped flag tells whether the reset had already started to change data. The required omnect-device-service version is >=0.46.1.
• The domain status enum has two variants that are not a real result. Unknown is the default and means "no result received yet", so the result dialog stays hidden. Unrecognized is the catch-all, so a status code that a later omnect-device-service adds still reaches the user.
• warning counts as success in the UI: the reset completed, but a partition needed a second format attempt. data_wiped is shown only on a failed result, where the device may be partly wiped and needs another reset.

wifi-commissioning-service probe via service-info

• GET /api/v1/service-info (wifi-commissioning-service 0.2.0, feat(api): add /api/v1/service-info exposing ble_enabled wifi-commissioning-service#3) is the only availability probe: it returns version, interface name and BLE state in one call. The probe no longer calls /api/v1/status and /api/v1/version.
• The version requirement works as for omnect-device-service: a semver requirement string (>=0.2.1) and the existing VersionInfo { required, current, mismatch }. WifiAvailability::Unavailable carries version_info: Option<VersionInfo>. None means the probe failed or the version does not parse; the device info shows unknown. An empty interface name also makes the service unavailable.
• An old wifi-commissioning-service does not block the UI: WiFi is optional, so the mismatch shows only in the WiFi line of the device info. ble_enabled is only logged.

Factory reset mode 4 removed

• The web API no longer accepts factory-reset mode 4; a request with it is rejected when the body is deserialized. Modes 1 to 3 are unchanged.

Reason

With omnect/omnect-device-service#207, error is null after a successful reset, but omnect-ui requires a String. So every factory-reset result fails to deserialize, and the UI shows a parse error instead of the result. The status codes were renamed and extended in the same change, so the old repr(u8) enum with four variants cannot name what the device reports.

The service-info probe needs one request instead of two. With the same requirement string and VersionInfo as omnect-device-service, both services report an unsupported version in the same way. The required version >=0.2.1 is the released wifi-commissioning-service tag.

Mode 4 ran a customer wipe script inside the scripted initramfs. omnect-os-init has no such script and answers mode 4 with Invalid, a reset that never runs. Rejecting the value here keeps the request from being sent at all.

This PR, omnect/omnect-device-service#207 and omnect/meta-omnect#697 have to reach a release together, so no component offers a mode the device refuses, and the UI can read the result the device reports.

[JoergZeidler]

Review of the three changes. All contracts are followed across core, generated types and the Vue shell; no correctness bugs. cargo +nightly fmt and cargo test --features mock pass locally. clippy could not run clean here because of a pre-existing unknown lint: clippy::unused_async_trait_impl in api.rs/certificate.rs (outside this PR) with no toolchain pinned — not a PR issue. tsc/biome/e2e were not run (no bun in my environment).

Inline comments hold the per-file findings. Two more that have no diff line to anchor to:

• Low — project-context.md not updated. The new backend module src/backend/src/version.rs is not in the "Project Structure" tree. The file's own rule asks for that section to be updated on a structure change.
• Minor — README.md:187 wording. It says the WiFi entry shows the "minimum required version"; the UI now shows current (required: >=X). Small wording drift, not a contract break.

Unverified (no action needed, just noting): the three RUSTSEC advisory IDs in the dep-bump commit are not checked (no cargo-audit config / no network), and the external service payloads (factory_reset v4, /api/v1/service-info) are checked against this repo's client and tests plus the named producer PRs, not the other repos' source.

[JoergZeidler]

All round-1 findings resolved in 718ecf6. Verified locally: cargo +nightly fmt --check and cargo test --features mock pass. Dropping the unused status field is serde-safe (no deny_unknown_fields), and the two e2e negative assertions are correct. clippy/tsc/biome/e2e not re-run in my environment; trusting your reported runs.