#205 AC#4: stm32f103c8 SPI auto-discovery is failing — SPIClass symbol missing from ELF

[zackees]

Symptom

The acceptance gate stm32f103c8_blink_with_spi_auto_discovers_library_205_ac4 in crates/fbuild-build/tests/stm32_acceptance.rs panics at line 87:

```
thread 'stm32f103c8_blink_with_spi_auto_discovers_library_205_ac4' panicked at crates/fbuild-build/tests/stm32_acceptance.rs:87:5:
AC#4: SPIClass symbol must be present in ELF — closes #202
```

This has been failing on every run of acceptance-205.yml, including on main, since at least the foundation phases landed (verified via gh run list --workflow acceptance-205.yml — every run since 2026-04-25 reports failure). It is not caused by any specific PR — it is a real AC#4 violation that has been silently red.

What the test does

1. Writes a tempdir project with [env:stm32f103c8], platform = ststm32, board = bluepill_f103c8, framework = arduino.
2. Writes a sketch that does `#include <SPI.h>` + `SPI.begin()`.
3. Runs `Stm32Orchestrator::build` with no manual library allowlist.
4. Expects the resulting ELF to contain a `SPIClass` symbol — proof that fbuild's library-selection layer auto-discovered `Arduino_Core_STM32/libraries/SPI/` and compiled it.

What's happening

The build itself succeeds (line 80 `assert!(result.success)` passes), so STM32duino is downloaded, the toolchain links, and an ELF is produced. But `SPIClass` is absent — meaning `SPI.cpp` was not compiled into the binary. The resolver isn't selecting the SPI library on stm32 builds.

Probable causes (one of these)

• `Stm32Orchestrator` doesn't pass STM32duino's bundled `Arduino_Core_STM32/libraries/` tree as discovered framework libraries when it calls `framework_libs::resolve_framework_library_sources_cached(...)` — empty input → empty selection → no SPI.cpp on the compile list.
• The STM32duino install layout puts SPI somewhere other than `/libraries/SPI/src/SPI.h`, so the path-prefix attribution doesn't trigger.
• `framework.get_framework_libraries()` returns an empty Vec for the STM32 framework variant.
• The walker's search paths don't include `Arduino_Core_STM32/libraries/SPI/src/`, so the `#include <SPI.h>` from the sketch resolves as unresolved + silently dropped (matching PIO LDF behavior).

Reproduction

```bash
uv run soldr cargo test -p fbuild-build --test stm32_acceptance -- --ignored
```

(Requires arm-gcc + STM32duino; downloads on first run.)

Why it matters for #205

AC#4 is the second of the two functional acceptance criteria the resolver was supposed to fix (along with AC#1 / #204 for teensyLC RAM overflow). Closing #205 without this passing means the issue's stated goal "stm32f103c8 Blink — the SPI dependency is discovered automatically" is not actually met.

Suggested first investigation step

Add temporary tracing to `Stm32Orchestrator` around the `framework.get_framework_libraries()` and `resolve_framework_library_sources_cached` calls — log the discovered library names + the resolver's `required_libraries` output. That will cleanly distinguish "framework returns empty" from "resolver fails to attribute" from "selected but not compiled".

Refs: #205 AC#4, #202.