hi3516av300: ship vendor SPL as :emmc board variant

[widgetii]

Why

We have two hi3516av300 cameras on the bench: one with SPI NOR flash (ether8), one with eMMC (ether1). They use different DDR chips, and the OpenIPC U-Boot for hi3516av300 ships an SPL targeting SPI NOR boards. On the eMMC board, defib's boot protocol completes every stage with ACKs from the bootrom, but the bootrom faithfully calls the agent at 0x81000000 — DDR isn't backed there, the CPU fetches garbage, and the link goes silent (0 bytes for 30s, no READY).

Two pieces here. The first builds on #102's variant infrastructure to carry an SPL blob; the second is the actual extracted-vendor variant.

What

SPL_BLOB schema addition

Optional profile field naming a binary file (resolved relative to the profile JSON's directory). The loader reads it into profile.spl_data. The agent-upload CLI prefers profile.spl_data over the downloaded U-Boot when set:

```python
if profile.spl_data is not None:
spl_data = profile.spl_data # variant SPL takes precedence
else:
spl_data = cached_fw.read_bytes() # fall back to OpenIPC U-Boot first 20K
```

Variant declaration looks like:

```json
{
"name": "hi3516av300",
"...": "...",
"variants": {
"emmc": { "SPL_BLOB": "hi3516av300-emmc-spl.bin" }
}
}
```

hi3516av300:emmc variant

20480 bytes extracted from a working eMMC av300 board's vendor U-Boot (eMMC offset 0, truncated at the gzip boundary at 0x5000). Lives at src/defib/profiles/data/hi3516av300-emmc-spl.bin.

End-to-end verified on real hardware:

Camera	--chip	Result
SPI NOR av300	hi3516av300	agent READY at t=0.3s
eMMC av300	hi3516av300	0 bytes for 30s (pre-existing failure mode)
eMMC av300	hi3516av300:emmc	agent READY at t=0.3s

Failure-diagnostic content update

The diagnostic message from #102 now actually has a real variant to suggest:

```
Known board variants for hi3516av300: emmc
Try: defib agent upload -c hi3516av300:emmc ...
```

Extraction recipe

Captured in kaeru `hi3516av300-emmc-variant-shipped-2026-05-15` for the next board family that hits this:

1. Catch vendor U-Boot prompt (^C bombardment)
2. `mmc dev 0` then `mmc read 0 0x82000000 0 0x40` — note: this U-Boot 2016.11 wants `mmc read DEV addr blk# cnt`, not `mmc read addr blk# cnt`
3. `loady 0x81000000` the defib agent, then `go 0x81000000`
4. `agent.read_memory(0x82000000, 0x6000)` to pull the bytes back
5. Truncate at the byte before the `\x1f\x8b\x08` gzip signature (0x5000 here) to drop the gzipped U-Boot tail
6. Drop into `src/defib/profiles/data/--spl.bin` and add a variant block

Test plan

• `uv run pytest tests/ -x --ignore=tests/fuzz` — 522 passed, 2 skipped (5 new tests in test_profiles.py covering blob resolution, missing-blob error path, blob-via-variant, real av300:emmc, real av300 base)
• `uv run ruff check` + `mypy` on changed files — clean
• Real-hardware: eMMC av300 reaches READY at t=0.3s with `--chip hi3516av300:emmc` (was 0 bytes for 30s before this PR)
• Real-hardware: SPI NOR av300 still reaches READY at t=0.3s with the base `--chip hi3516av300` (no regression)
• `.bin` gitignore got a negation rule for `src/defib/profiles/data/.bin` so SPL blobs don't get hidden

Aside

Found a separate routeros power-controller bug while iterating: `power_off → power_on` over a port that was already off restores it to "off" because `power_off` saves the current state (off) and `power_on` restores it. Worked around in test scripts via `_set_poe(port, 'forced-on')`. Worth fixing separately.

🤖 Generated with Claude Code