Tech-debt: deduplicate _parsePossibleChannels shared between usp_wifi_data_service and usp_wifi_settings_service

[AustinChangLinksys]

Summary

_parsePossibleChannels — which parses a TR-181 PossibleChannels string into a sorted list of channel numbers — is duplicated verbatim in two service files. Any future fix (e.g. sentinel filtering, range-parsing hardening) must be applied in both places; missing one causes silent divergence between the two services.

Locations

• lib/page/wifi_settings/services/usp_wifi_data_service.dart (_parsePossibleChannels, ~line 424)
• lib/page/wifi_settings/services/usp_wifi_settings_service.dart (identical top-level function, ~line 622)

Impact

• Introduced/surfaced alongside [Suggestion] Dashboard: WFi Status: It is recommended to use a drop-down menu to allow users to select which channel to use #1023 (PR feat(wifi): add channel dropdown to edit dialog (#1023) #1027).
• Not a functional bug today — behaviour is identical UPDATE (2026-07-02): the two copies have now DIVERGED. The usp_wifi_data_service copy was hardened (sentinel "0" filtering + range-notation guard) while the usp_wifi_settings_service copy was not. They are no longer identical — which is precisely the drift hazard this issue warned about, now realized.
• The usp_wifi_settings_service copy lacks a bounds.length != 2 check and a removeWhere((ch) => ch <= 0) filter, so malformed backend input ("0", "0-13") would parse into an unclean list. This is a low-severity defensive-coding gap, not a user-reachable functional bug — the settings-page dropdown is a selection menu (no free-text input), and PR feat(wifi): add channel dropdown to edit dialog (#1023) #1027 does not modify that page's UI. (See re-evaluation in PR feat(wifi): add channel dropdown to edit dialog (#1023) #1027 review.)

Suggested fix

Extract to a single shared utility (e.g. lib/core/utils/wifi_channel_utils.dart, parsePossibleChannels(String raw) -> List<int>) and import from both services. Move the associated unit tests to cover the shared function once.

★ The shared utility MUST carry the hardened logic (sentinel "0" filtering, bounds.length != 2 guard, range-notation coverage), taking the usp_wifi_data_service copy as the correct baseline — NOT the un-hardened usp_wifi_settings_service copy. Extracting from the wrong baseline would spread the gap rather than close it. This subsumes the "C-1" finding raised in PR #1027 review (Round 3), which was downgraded there and folded into this issue.

Notes

Related functional fixes (band normalization for DFS annotation, "0" sentinel filtering, range-notation test coverage) were handled directly in #1023 / PR #1027 for the usp_wifi_data_service path. This issue tracks the deduplication tech-debt AND re-convergence of the two now-diverged copies (hardening the settings-service path in the process), deferred from #1027 to avoid scope-creep.

[AustinChangLinksys]

Updated per PR #1027 Round 3 re-evaluation (2026-07-02): the two _parsePossibleChannels copies have diverged — usp_wifi_data_service was hardened, usp_wifi_settings_service was not. The C-1 finding from #1027 (channel-0 reaching the dropdown) was downgraded there — no user-reachable path in that PR (dropdown is a selection menu, and the settings-page UI isn't touched) — and folded into this issue. When de-duplicating, the shared utility must take the hardened data-service copy as baseline so the settings path is hardened too, not the reverse.