fields.json schema changed in 0.2.0: existing users lose saved settings on upgrade

[nedseb]

Severity: Low / Compat — existing users lose their saved fields after upgrading from 0.1.x to 0.2.0.

Before the wireless-stack work, src/main_widget.rs serialized EasyDapLink directly into fields.json:

{
  "bootloader_path": "...",
  "firmware_path": "...",
  "user_file_path": "...",
  "target_waiting_time": 10,
  "target_name": "STEAMI"
}

After the merge, the new MainWindow wraps both tabs and the file is now:

{
  "tab_daplink": {
    "bootloader_path": "...",
    ...
  },
  "tab_ws": { ... }
}

In src/ui/main_window.rs:49-66, serde_json::from_slice::<Self>(...) fails on the old shape; the error is logged with eprintln!("Failed to deserialize settings. Error: {e}") and the user starts from an empty form. They have to re-pick all their files and retype the target name.

Suggested fix — soft migration

Try the new shape first; on failure, attempt the legacy shape and lift it into tab_daplink:

match serde_json::from_slice::<Self>(&content) {
    Ok(obj) => {
        self.tab_daplink = obj.tab_daplink;
        self.tab_ws = obj.tab_ws;
    }
    Err(_) => {
        // Try legacy single-tab schema as a one-shot migration.
        if let Ok(legacy) = serde_json::from_slice::<TabDaplink>(&content) {
            self.tab_daplink = legacy;
            // tab_ws keeps its default
            // settings will be rewritten in the new shape on next CloseRequested
        } else {
            eprintln!("Failed to deserialize settings (no compatible schema)");
        }
    }
}

Settings are rewritten on CloseRequested, so a single successful run lifts the file to the new shape transparently.

Not blocking — for a small internal tool the cost is "users re-fill the form once" — but the migration is cheap.

Spotted in post-merge review.