profiles: per-board variant overrides; loud diagnostic when agent stays silent

[widgetii]

Why

Two hi3516av300 cameras side-by-side. Same chip silicon, same defib code, same boot protocol, same TAIL ACKs from the bootrom. The agent uploaded to 0x81000000 ran cleanly on the SPI NOR variant and hung silently on the eMMC variant. The bootrom source (`OpenIPC/openhisilicon: bootrom/hi3516av300/re/bootloader.c:uart0_recv_payload`) confirmed the protocol is fine — `((foreign_fn)frame[6])()` is called after every ACKed TAIL. What differed was `DDRSTEP0` — defib's per-chip DDR init is calibrated for ONE board and doesn't bring DDR up on the other variant, so the bootrom faithfully jumps to 0x81000000 but the CPU fetches garbage there and hangs without writing a single byte to UART. Full investigation captured in kaeru `av300-ddr-init-is-per-board-not-per-chip-2026-05-15`.

What

Two things, both keyed off the realisation that DDR init is per-board, not per-chip.

Per-board variant support in profiles

Optional `variants` map in profile JSON. Each variant overrides matching top-level keys (typically `DDRSTEP0`, sometimes `PRESTEP0`):

```json
{
"name": "hi3516av300",
"DDRSTEP0": [...],
...
"variants": {
"emmc": { "DDRSTEP0": [...board-specific DDR init...] }
}
}
```

CLI accepts `--chip hi3516av300:emmc` consistently. Variant suffix gets stripped in chip-keyed lookups (`firmware_url`, `get_cached_path`, `get_agent_binary`) — those resources are per-chip. Profile loader pops `variants` before pydantic validation and merges in via `dict.update()`, so the `SoCProfile` model itself stays variant-unaware. Aliases still work transparently (`hi3516dv300_alias:emmc` resolves the alias chain and then applies the variant on the final target).

Loud diagnostic when agent stays silent

`defib agent upload` / `defib agent flash` used to print one red line when the agent never returned READY:
```
Agent not responding
```

Now it explains what's happening:
```
Agent not responding
Boot-protocol upload completed but the agent never sent READY.

Most common cause: the chip profile's DDR init (PRESTEP0/DDRSTEP0)
doesn't match this board's DDR layout. The bootrom faithfully calls
the agent at 0x81000000, but DDR isn't backed there, so the CPU
fetches garbage and hangs silently (no UART output).

No board variants declared for hi3516av300.

Manual workaround (vendor U-Boot must be intact in flash):

1. power-cycle the camera
2. hold Ctrl-C to break U-Boot autoboot
3. at the U-Boot prompt: loady 0x81000000
4. YMODEM-send agent-.bin
5. go 0x81000000
   ```

When variants are declared, the message names them and suggests `defib agent upload -c hi3516av300:` as the next step. JSON output mode wraps the same text under a `diagnostic` key.

Not in scope

The actual `hi3516av300:emmc` variant DATA — we don't have working DDR init bytes for the eMMC board. Extracting them from that board's vendor U-Boot is the follow-up task. This PR ships only the infrastructure plus the diagnostic.

Test plan

• `uv run pytest tests/ -x --ignore=tests/fuzz` — 517 passed, 2 skipped (21 new tests: 17 in test_profiles.py, 4 in test_cli.py)
• `uv run ruff check` on changed files — clean
• `uv run mypy` on `src/defib/profiles/`, `firmware.py`, `agent/client.py` — no issues
• `defib list-chips` / `defib agent upload --help` smoke-test — unchanged
• Real-hardware findings from the investigation are preserved in kaeru (`av300-ddr-init-is-per-board-not-per-chip-2026-05-15`, `cv500-agent-jumps-from-vendor-uboot-not-bootrom`).

🤖 Generated with Claude Code