README: add ssh_key_path migration note + document normalization rules

Docs pointing at the new state-dir default were updated in b1fbf69;
what was still missing is the migration guidance the review asked for.

Add a short note under the ssh_key_path bullet covering:

- what moved (~/.config/banger/ssh/id_ed25519 →
  ~/.local/state/banger/ssh/id_ed25519)
- that users with the old path hardcoded in config.toml are safe
  (the narrowed legacy-dir cleanup preserves the enclosing dir when
  ssh_key_path points inside it)
- that unsetting the key and letting banger manage the new default
  is also fine — the only caveat is existing VMs need a
  stop-and-start to re-sync authorized_keys

Also document the new normalization rules (~/ expansion, absolute
required) on the ssh_key_path bullet itself so users know what's
accepted before they hit a load error.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

README.md

@@ -152,11 +152,23 @@ Most commonly set:
   (default `debian-bookworm`, auto-pulled from the catalog if not
   local).
 - `ssh_key_path` — host SSH key. If unset, banger creates
-  `~/.local/state/banger/ssh/id_ed25519`.
+  `~/.local/state/banger/ssh/id_ed25519`. Accepts absolute paths or
+  `~/`-anchored paths; `~/foo` expands against `$HOME`. Relative
+  paths are rejected at config load.
 - `firecracker_bin` — override the auto-resolved `PATH` lookup.
 
 Full key list in `internal/config/config.go`.
 
+> **Migration note.** The auto-generated default moved from
+> `~/.config/banger/ssh/id_ed25519` to
+> `~/.local/state/banger/ssh/id_ed25519`. If you have the old path
+> hardcoded in `config.toml`, either keep it (banger preserves the
+> directory when `ssh_key_path` points inside it) or unset the key
+> and banger will manage the new default for you. The first time the
+> daemon starts against the new default, guest VMs need a fresh
+> workspace sync (`banger vm stop && start`, or `--rm` flows are
+> unaffected) so their `authorized_keys` pick up the new fingerprint.
+
 ### `vm_defaults` — sizing for new VMs
 
 Every `vm run` / `vm create` prints a `spec:` line up front showing