fix: implement recreate strategy dispatch and flow (lost in SLIP-71 half-merge)

[mitchelljphayes]

The bug

SLIP-71 (recreate deploy strategy) was half-merged on main — lost during the earlier GitButler→git migration. The scaffolding survived (DeployStatus variants, rollback_failed field, RuntimeBackend trait methods) but the actual logic — strategy dispatch + execute_recreate_deploy_container + rollback + validation — was never applied. The config accepted strategy = "recreate" but deploy.rs silently always ran blue-green.

How we found it

Deploying a real app — a single-writer DuckDB catalog server (Quack) — on Arrakeen. The first deploy worked, but redeploy failed: slip started the new container while the old still held DuckDB's exclusive file lock (blue-green behavior), so the new container couldn't open the catalog → health check failed → rollback. recreate is supposed to prevent exactly this.

The fix

• Strategy dispatch in execute_deploy_inner (container path)
• execute_recreate_deploy_container: stop old → remove route → start new → health check → set route → remove old
• 3-tier rollback: restart old → recreate from previous_tag → catastrophic
• validate_deploy_strategy in config.rs (accept blue-green/recreate)
• Blue-green behavior unchanged

Verified live on Arrakeen

Quack redeploy now: stops old first → starts new → health passes (lock free) → removes old. One instance at a time, catalog persists across redeploy (identical md5). 386 tests pass, clippy clean.