refactor: restructure firmware directory

[hgrf]

No description provided.

[hgrf]

@copilot fix the CI/CD

[Copilot]

@copilot fix the CI/CD

Fixed in d2856e5. The root cause was that the workspace Cargo.toml had a [patch.crates-io] entry for esp-idf-svc pointing to vendor/esp-idf-svc, which isn't available in the Quality Checks job. When cargo clippy --manifest-path landerctl/Cargo.toml ran, Cargo read the workspace root and tried to load the patch, failing because the vendor directory didn't exist.

The fix makes fw its own standalone workspace (adding [workspace] to fw/Cargo.toml and removing it from the root workspace members). The esp-idf-svc patch and firmware build profiles are now scoped to fw/Cargo.toml only. I also fixed the firmware artifact upload path (fw/target/...) and added a firmware format check step to the CI.

[hgrf]

@copilot fix the builds in the CI/CD

[Copilot]

@copilot fix the builds in the CI/CD

Fixed in 4a9fce9. Three issues were causing the build failures:

1. Build Linux AppImage and Build macOS App: The landerctl binary was being copied from landerctl/target/release/landerctl, but since landerctl is now a member of the root workspace, Cargo places output at target/release/landerctl. Updated both copy commands.

2. Build Firmware: The vendor/esp-idf-svc directory (referenced in fw/Cargo.toml's [patch.crates-io]) wasn't present in CI. Added:

   • patches/esp-idf-svc.patch: Fixes the .try_into().unwrap() panic on unknown BLE disconnect HCI reason codes by using .unwrap_or(GattConnReason::Unknown)
   • scripts/setup_esp_idf_svc.sh: Clones esp-idf-svc at v0.52.1 and applies the patch (following the same pattern as setup_tray_item.sh)
   • A setup step in the Build Firmware CI job to run this script before building

[hgrf]

@copilot Ok somehow the esp-idf-svc patch in the firmware build got messed up, figure it out please. Is there any way I can get you to keep working until the CI/CD is all green?

[Copilot]

@copilot Ok somehow the esp-idf-svc patch in the firmware build got messed up, figure it out please. Is there any way I can get you to keep working until the CI/CD is all green?

Fixed in abe1d6e. The patch file was malformed — I had hand-crafted it with wrong hunk line counts (-717,7 instead of -719,7 for the first client.rs hunk, and the wrong context function name), which caused git apply to error with "patch fragment without header at line 30".

The fix: cloned esp-idf-svc at HEAD, applied the changes with sed, then exported the patch with git diff to get a properly formatted patch. Verified it applies and reverses cleanly.

Regarding keeping the CI green: the runs I push are showing as action_required because GitHub requires you to approve bot-triggered workflow runs. Could you approve/re-run the latest CI run (#101) once you see this? I'll keep watching and address any remaining failures.