`gmake setup` (through Omicron's `cargo xtask releng`) panicked

I'm not sure what's going on here or what the fix should be -- my apologies if this is in the wrong place.

I tried to run cargo xtask releng in Omicron to build a TUF repo. It initially blew up because $HOME/helios was from 9 months ago. I did a git pull there and reran cargo xtask releng. I got this:

dap@ivanova omicron-work $ cargo xtask releng
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.47s
     Running `target/debug/xtask releng`
   Compiling ring v0.17.14
   Compiling rustls v0.23.37
...
[  recovery-image] Mar 02 22:16:45.601 INFO E| blob file "Appb_GN_BIST_Ddr4_Rdimm_Dmem.csbin" not found or readable
[  recovery-image] Mar 02 22:16:45.601 INFO E| blob file "Appb_GN_BIST_Ddr4_Lrdimm_Imem.csbin" not found or readable
[  recovery-image] Mar 02 22:16:45.601 INFO E| blob file "Appb_GN_BIST_Ddr4_Lrdimm_Dmem.csbin" not found or readable
[  recovery-image] Error: 
[  recovery-image] thread '<unnamed>' panicked at src/archive.rs:77:33:
[  recovery-image] called `Result::unwrap()` on an `Err` value: RecvError
[  recovery-image] note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
[  recovery-image] exec ["cargo", "xtask", "gen", "--amd-firmware", "/home/dap/helios/projects/amd-firmware", "--payload", "/home/dap/omicron-work/out/releng/os-recovery/phbl/x86_64-oxide-none-elf/release/phbl", "--app", "/home/dap/helios/image/amd/milan-gimlet-b-1.0.0.h.toml", "--image", "/home/dap/omicron-work/out/releng/os-recovery/gimlet.rom", "--root", "/home/dap/helios/image/amd", "--config", "/home/dap/helios/image/amd/milan-gimlet-b.efs.json5"]: failed ExitStatus(unix_wait_status(256))
[      host-image] Mar 02 22:16:45.605 INFO O| Mar 02 22:16:45.605 INFO rolled back to input snapshot; work may begin
[      host-image] Mar 02 22:16:45.605 INFO O| Mar 02 22:16:45.605 INFO CREATE DATASET: rpool/images/dap/host/work/sled/ramdisk
[  recovery-image] 
[  recovery-image] real     7:49.090188319
[  recovery-image] user     6:22.395279114
[  recovery-image] sys        46.661625915
[  recovery-image] trap        0.116735230
[  recovery-image] tflt        2.055414155
[  recovery-image] dflt        1.214461723
[  recovery-image] kflt        0.001849334
[  recovery-image] lock    36:15.304641142
[  recovery-image] slp     45:58.838911913
[  recovery-image] lat        10.789008595
[  recovery-image] stop        2.081492097
Mar 02 14:16:45.607 ERRO [recovery-image] process exited with exit status: 1 (469.097639728s)
[      host-image] Mar 02 22:16:45.608 INFO O| Mar 02 22:16:45.608 INFO STEP 0: remove_files, from: /home/dap/helios/image/templates/sled/ramdisk-02-trim.json
Error: command `IMAGE_DATASET=rpool/images/dap/recovery ptime -m /home/dap/helios/helios-build experiment-image -o /home/dap/omicron-work/out/releng/os-recovery -F 'optever=0.39.455' -P /dangerzone/omicron_tmp/.tmpHzizBK/proto/recovery/root -N 'recovery c0717a4/${os_short_commit} 2026-03-02 21:57' -s recovery -R -p 'helios-dev=https://pkg.oxide.computer/helios/2/dev/'` exited with exit status: 1
dap@ivanova omicron-work $ 

On @iliana's suggestion, I checked the status of $HOME/projects/amd-firmware:

dap@ivanova amd-firmware $ git status
On branch master
Your branch is up to date with 'origin/master'.

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        deleted:    BRH/0.0.7.3/APOB_NV_BRH.bin
        deleted:    BRH/0.0.7.3/AblPostCode.h

...
        deleted:    SSP/1.0.0.e/bl_syscall.h
        deleted:    SSP/1.0.0.e/rome.pi.relnotes-1.0.0.e-20220616.html

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        BRH/

There are several hundred files reported as deleted there. xie suggested:

I think some combination of gmake setup and cargo xtask releng isn't good at making sure the git repos under projects/ are actually up to date

Regardless of that, the unwrap() with RecvError could be a more useful message.

Start at src/archive.rs:77 and reproduce the panic through cargo xtask releng or gmake setup. Trace how repositories under projects/, especially amd-firmware, are prepared before the releng run; done should include a useful failure message for the RecvError and a clear resolution for repository state handling.