gui: Danger Zone in the Updates tab — reset levels for a wedged node

[mrjeeves]

What

The AllMyStuff half of the Danger Zone (companion to MyOwnMesh #106). An in-app way to reset a node, so recovering a stuck install doesn't mean hand-deleting files under ~/.myownmesh. A Danger Zone card at the bottom of Settings → Updates (desktop only), with three graduated, two-click-armed levels:

• Leave the fleet — drop this device from its fleet (ownership, fleet key, signed fleet roster); keep other meshes + settings. Reuses fleet_leave.
• Reset networking — leave the fleet and forget every mesh (rosters + signed state), keeping the device identity.
• Factory reset — wipe everything (identity, config, all meshes, fleet ownership); the device becomes brand-new to every peer.

Why the reboot

Each action reboots the whole stack when it fires. The myownmesh daemon is the real datastore, so a reset that only deletes files gets undone by an in-memory cache re-persisting on the next write. So each command clears state, the daemon exits, and restart_app relaunches — the supervised node and a fresh daemon come back on clean disk (identity regenerated on a factory reset).

Changes

• node (mesh.rs): reset_networking (fleet_leave + daemon ForgetAllNetworks) and factory_reset (clear ownership so it can't re-persist, then daemon FactoryReset wipes the shared state dir); dispatched from node_control.rs.
• allmystuff-protocol: ForgetAllNetworks / FactoryReset on the daemon Request mirror.
• GUI: reset_networking / factory_reset Tauri commands (restart_app already existed), resetNetworking / factoryReset bindings, the dangerLeaveFleet / dangerResetNetworking / dangerFactoryReset store methods, and the Danger Zone UI (theme-aware, --danger vars).

Dependency

Reset networking and factory reset need the myownmesh daemon that adds ForgetAllNetworks / FactoryReset (#106 over there). Per the plan, the .myownmesh-rev pin gets bumped as that release cuts — this PR intentionally leaves it. Against an older daemon, Reset networking still leaves the fleet (the forget-all just no-ops with a parse error); Leave the fleet works regardless.

Testing

node + protocol + Tauri crates: cargo check / clippy --all-targets -D warnings / fmt clean; svelte-check clean (0 errors).

⚠️ The wipe + backend are compile-verified, but the reboot lifecycle (node/daemon exit → app relaunch → fresh stack) can't run in CI — it wants a smoke test on a real desktop install.

🤖 Generated with Claude Code

https://claude.ai/code/session_018x1RV6ppUdMDTHxScVo26L

---

Generated by Claude Code

[mrjeeves]

The Node · windows-latest failure is a pre-existing Windows-only native flake, not from this PR.

Evidence:

• Node · ubuntu-latest and Node · macos-latest both passed the identical test suite; only Windows crashed.
• Rust · windows-latest passed, so the code compiles and links fine on Windows.
• The failure isn't a Rust panic/assertion — it's a native STATUS_ACCESS_VIOLATION (0xc0000005), and it hit mid-run right after byte_queues::tests::framing_is_byte_exact, inside the media test suite (openh264 / cpal / nokhwa native libs). This PR's diff is pure-Rust async reset handlers + a couple of dispatch arms — no native or unsafe code, and nothing that runs in those tests.

So the change is green everywhere the crash didn't randomly land. I don't have permission to re-run the job from here (the API returns 403 Resource not accessible by integration), so a maintainer "Re-run failed jobs" click should clear it — or it'll re-run clean on the next push. Worth a separate look at the Windows media tests if this recurs, but it's out of scope for this PR.

---

Generated by Claude Code