feat: import whole device configuration (stacked on #1940)

[bruschill]

What changed?

Adds an Import Device Configuration action to Settings → Tools — the inverse of the Export Configuration feature (meshtastic#1940). It applies a saved binary DeviceProfile (.cfg) file to the connected node.

Stacked on meshtastic#1940. This PR targets feat/export-device-config so the diff is import-only. Retarget to main once the export PR merges. Import reuses the export branch's DeviceProfile format and MeshtasticChannelURL (from meshtastic#1983).

• Meshtastic/Import/DeviceProfileImport.swift — pure, device-free core. parseDeviceProfile defensively decodes untrusted bytes (size cap before decode). DeviceProfileImportPlan(profile:currentUser:) is the has*-gated inverse of exportDeviceProfile(): it emits an ordered [ImportItem] plan and is the single source of coverage truth so export/import can't silently drift. Items are grouped into 8 coarse toggle sections and carry isSensitive/causesReboot flags.
• Meshtastic/Import/DeviceProfileImporter.swift — a ProfileApplyGateway seam plus the apply engine (sequential, isConnected pre-checks, abort-on-first-failure). The production gateway forwards each item to the existing save*Config / saveUser / saveChannelSet / saveRtttlConfig / saveCannedMessageModuleMessages / setFixedPosition calls, with fromUser == toUser == the connected node (self-admin, no session passkey).
• Meshtastic/Views/Settings/ImportDeviceProfileView.swift — review sheet: per-section toggles, live sensitive-material + reboot banners, a confirmation gate, per-item progress, and an applied/failed/skipped result summary.
• Meshtastic/Views/Settings/Tools.swift — the Import section + .fileImporter([.meshtasticDeviceProfile]) with a capped read, parse, and the review sheet.
• AccessoryManager+ToRadio.swift — new setFixedPosition(_:fromUser:toUser:) overload to restore explicit coordinates from a profile (the existing overload only uses the phone's live GPS fix).

Design decisions worth a look:

• Apply order is fixed and reboot-safe. The plan emits items in a strict order (owner → radio/device → modules → personalization → fixed position → network → bluetooth → security → Channels & LoRa last). The UI filters by section but never reorders, so the reboot-prone LoRa/channel step is always last and can't drop later sends. Network/Bluetooth are placed late because they can drop the transport the import runs over.
• Security & Identity defaults OFF. Importing a foreign private/admin key rewrites this node's cryptographic identity and can break existing DMs / lock local admin, so it's a deliberate opt-in. Every other present section defaults ON, preserving a one-tap "restore my device" flow.
• LoRa/channel dedupe. Export writes the same LoRaConfig into both config.lora and the channel URL's ChannelSet. The plan emits exactly one terminal item — the channel URL when it's a valid replace-mode set with a LoRa config, otherwise the standalone LoRa config (add-mode or LoRa-less URLs fall back so the region is still restored).
• Owner merge preserves identity. The owner step starts from the live node.user.toProto() and overrides only long/short name, so id/hwModel/publicKey/role are never wiped by setOwner.

Why did it change?

The Android app and meshtastic CLI can import a device's full configuration from a .cfg; iOS/macOS could export (meshtastic#1940) but not import. This closes the loop so a backup can be restored — or a config cloned onto a second node — across the Meshtastic ecosystem.

How is this tested?

• New DeviceProfileImportTests (Swift Testing) — 22 tests, all passing: defensive parse + export↔import round-trip, coverage parity with export (all 8 device + 15 module configs; meshBeacon/remoteHardware intentionally absent), apply ordering, LoRa/channel dedupe including the add-mode and LoRa-less fallbacks, fixed-position gating, owner-identity preservation at the plan level, sensitivity/reboot flags, and the engine's abort/skip/reboot semantics via a mock gateway.
• Full app build succeeds for the iOS 18 simulator (Debug).
• The plan was reviewed field-by-field against exportDeviceProfile() to keep import/export symmetric.

Screenshots/Videos (when applicable)

Checklist

• My code adheres to the project's coding and style guidelines.
• I have conducted a self-review of my code.
• I have commented my code, particularly in complex areas.
• I have verified whether these changes require updates to the in-app documentation under docs/user/ or docs/developer/, and updated accordingly. Added a Tools section to docs/user/settings.md (NFC, Export & Import Configuration) and regenerated the bundled HTML.
• I have tested the change to ensure that it works as intended.

---

Notes for reviewers

• Sensitive material is written to the device in plaintext. The .cfg carries the private key, admin keys, channel PSKs, and Wi-Fi/MQTT passwords, and import applies them (strictly more dangerous than export, which only reads). Handling: Security & Identity defaults OFF, a live banner itemizes exactly what a given selection overwrites, and a confirmation dialog gates apply. No secret is logged.
• Export ↔ import remain two hand-maintained mirrors. DeviceProfileImportPlan is the inverse of exportDeviceProfile(); a round-trip test locks the format, but a shared single source of truth between the two is the deeper follow-up (also noted on feat: export whole device configuration (#1924) meshtastic/Meshtastic-Apple#1940).

🤖 Generated with Claude Code

[bruschill]

No longer needed — the export and import work is combined in the upstream PR meshtastic#2023.