fix: [Internet Settings] connection type incorrectly displays as Bridge after saving MTU, reverts to DHCP on re-entry

[PeterJhongLinksys]

Description

After saving an MTU change on the Internet Settings page, the displayed connection type changes to Bridge. However, navigating back and re-entering the page shows the connection type as DHCP again.

Root Cause

The issue likely involves the interaction between _saveWanSettings() and the connection type detection logic:

1. Save logic (lib/page/internet_settings/services/usp_internet_settings_service.dart:241): When typeChanged is false (only MTU was edited), addressingType is sent as null (skipped). However, a separate bridgeEnabled write may still occur or the device may return an ambiguous state after the MTU update.

2. Type detection (lib/page/internet_settings/models/usp_wan_connection_type.dart:16): fromRawFields() determines Bridge mode when addressingType is empty AND bridgeEnabled is true:

   if (bridgeEnabled && addressingType.isEmpty) return bridge;

   If the post-save re-fetch returns an empty addressingType with bridgeEnabled = true, the type is incorrectly detected as Bridge.

3. On re-entry, a fresh fetch retrieves the correct device state showing DHCP, exposing the inconsistency as a transient display issue.

Expected Behavior

Saving MTU should not alter the displayed connection type. The post-save state should correctly reflect the unchanged connection type.

[PeterJhongLinksys]

[Root cause]
After saving non-type fields (e.g. MTU), the post-save re-fetch from the device transiently returns an empty addressingType. Combined with bridgeEnabled being always true on most routers (it controls the LAN-side L2 bridge, not WAN bridge mode), fromRawFields() misdetects the connection type as Bridge.

The underlying issue is that the current Bridge Mode detection logic (addressingType empty + bridgeEnabled true) is fragile, and the Bridge Mode write path is effectively a no-op (writes addressingType = 'DHCP' + bridgeEnabled = true, both of which are normal DHCP state).

[Solution]
Added a one-shot _preservedConnectionType guard in UspInternetSettingsNotifier:

• performSave(): when connection type was NOT changed, remembers the current type
• performFetch(): if the post-save fetch returns a different type (transient misdetection), preserves the known type and logs a warning
• Guard is consumed after one use to avoid affecting subsequent normal fetches

Also reverted the failed fix of always sending addressingType in _saveWanSettings.

Added TODO comments pointing to #762 for proper Bridge Mode implementation via TR-181 Device.Bridging.Bridge.{i}.Port.{i}.

[AustinChangLinksys]

🔗 Root Cause Identified

This issue is a downstream effect of a firmware problem that prevents WAN mode switching.

🚨 Root Cause

FW-001: AddressingType Set No-Op - USP Set operations on AddressingType return success but don't actually change the WAN mode.

📋 Tracking

• Root Cause Tracker: [FW-CORE] Critical TR-181 Path Fixes (6 items) #789 - [FW-CORE] Critical TR-181 Path Fixes
• Master Tracker: [MASTER] USP/TR-181 Integration Status - Root Tracker #788 - [MASTER] USP/TR-181 Integration Status
• Priority: P0 Critical Blocker

⚡ Resolution Path

1. Firmware Team: Fix FW-001 AddressingType Set operation
2. Result: This UI issue will be automatically resolved

🔗 Related Issues (same root cause)

• fix: [Internet Settings] connection type switching produces unexpected form state #758: Connection type switching form state issues → FW-001
• fix: [Internet Settings] MTU auto toggle is non-functional #757: MTU auto toggle non-functional → FW-001

Status: ⏳ Waiting for firmware fix - no UI changes needed