v0.2: SlotConfig.device refactor + capabilities.toml schema_version=2 migration

[thinmintdev]

What to build

Refactor SlotConfig.backend (overloaded enum mixing providers + backends — vulkan|rocm|flm|moonshine|kokoro|cpu) to SlotConfig.device (hardware-preference only — gpu-rocm | gpu-vulkan | cpu | npu). Default gpu-rocm for new installs.

Auto-migration on hal0-api boot when capabilities.toml schema_version=1 detected:

1. Backup current config to capabilities.toml.v1.bak
2. Rewrite backend → device per slot (mapping: vulkan→gpu-vulkan, rocm→gpu-rocm, flm→npu, moonshine/kokoro→cpu, cpu→cpu)
3. Bump schema_version=2
4. Validate result against Pydantic schema

Also expose hal0 capabilities migrate-to-lemonade CLI for manual rerun / diagnostic.

Downgrade preservation: when v0.1.x reads schema_version=2, it falls back to reading capabilities.toml.v1.bak if present.

Acceptance criteria

• SlotConfig Pydantic schema has device field; backend removed
• LemonadeProvider maps device → Lemonade recipe:backend correctly per modality
• Auto-migration runs idempotently on hal0-api boot
• capabilities.toml.v1.bak preserved on upgrade
• CLI command hal0 capabilities migrate-to-lemonade works + reports diff
• Unit tests cover v1 → v2 migration with each enum mapping
• v0.1.x downgrade path (using .v1.bak) validated
• Doc updated: docs/reference/configuration.md (or equivalent) reflects new field

Blocked by

• v0.2: Primary slot served by Lemonade end-to-end (tracer bullet) #140