CI flake: linker error building CLI

[clockwork-labs-bot]

Detected by CI Gremlin after a failed GitHub Actions attempt succeeded on rerun.

Tests:

• Build and test wasm bindings

Error:
error: linking with cc failed: exit status: 1
|

Failed job runs:

• https://github.com/clockworklabs/SpacetimeDB/actions/runs/27853147083/job/82435739509 (Build and test wasm bindings, attempt 1 -> 2)

Context:

• none

[clockwork-labs-bot]

Root cause appears to be a transient malformed native object during the Linux CLI build, not a wasm-bindings test failure and not PR #5378 content.

Evidence:

• Failed job: https://github.com/clockworklabs/SpacetimeDB/actions/runs/27853147083/job/82435739509
• Rerun that passed on the same PR/head run: https://github.com/clockworklabs/SpacetimeDB/actions/runs/27853147083/job/82440009517
• Both attempts restored the same Rust cache key: v1-spacetimedb-Linux-x64-86d4966b-c8bc3c71.
• Attempt 1 ran on ghr-github-self-hosted-ubuntu-14900k-05-spacetimedb-14-a18dcaaf; attempt 2 ran on ghr-github-self-hosted-ubuntu-14900k-05-spacetimedb-14-00a10fc4.
• The actual failure happened in the cargo build -p spacetimedb-cli prebuild inside cargo ci wasm-bindings, before the later cargo update / module build phase.
• The linker rejected an object inside the freshly built CLI rlib:

rust-lld: error: /home/runner/actions-runner/_work/SpacetimeDB/SpacetimeDB/target/debug/deps/libspacetimedb_cli-b1462f262d2439a2.rlib(spacetimedb_cli-b1462f262d2439a2.spacetimedb_cli.6ea959aa1b3dcfe7-cgu.031.rcgu.o):(.eh_frame): invalid CIE reference
collect2: error: ld returned 1 exit status
error: could not compile `spacetimedb-cli` (bin "spacetimedb-cli") due to 1 previous error

That .eh_frame / CIE error means lld saw invalid unwind metadata in an input object. Since the same merge SHA passed on rerun and there are no code errors before the linker failure, the most likely cause is runner-local object corruption or a transient rustc/lld/filesystem issue while producing or reading that object. A bad shared cache artifact is less likely because the rerun restored the same cache key and passed.

I only found this one auto-filed occurrence of the signature in current SpacetimeDB issues. If it repeats, I would treat it as infra/toolchain and capture the failing runner plus cache key; the next mitigation to try would be disabling target-cache restore for this job or forcing a clean target/debug/deps before the CLI prebuild to distinguish restored-target contamination from fresh compiler/linker corruption.