feat(cli): expose `--live-fork` on `forkd fork` / `from-image` / `run` for spawn-time opt-in

[WaylandYang]

Gap

Phase 7.1 (REST live_fork: true on POST /v1/sandboxes) and Phase 7.3 (Controller.spawn_sandboxes(live_fork=True) in Python/TS/MCP SDKs) shipped the spawn-time live-fork opt-in. The CLI did not get a matching flag.

This means:

• The doc comment on forkd snapshot --live (added in Phase 7.2) tells users "the source must have been created with `--live-fork`," but that flag doesn't exist.
• A CLI-only workflow can't currently spawn a live-fork-capable source — you have to drop into the SDK or curl REST to set live_fork: true.

Scope

Add --live-fork (bool flag) to:

• forkd fork (spawns N children from a registered snapshot)
• forkd from-image (Docker → rootfs → boot → register, then optionally spawn one)
• forkd run (one-shot spawn)

For each, plumb the flag through to POST /v1/sandboxes body's live_fork: true (the daemon already accepts it).

Acceptance

• forkd fork --tag X -n 1 --live-fork spawns a live-fork-capable child; forkd snapshot --from-sandbox <id> --live then succeeds against it
• clap docstring explains the kernel/FC prereqs (link to docs/VENDORED-FIRECRACKER.md)
• forkd snapshot --live doc comment can drop the "source must have been created with --live-fork" caveat into being literally true on the CLI
• README's bash snippet (currently calls out the gap explicitly) can be tightened to remove that note

Why follow-up not blocking

mode: \"live\" itself works today via SDK or REST — this is purely CLI ergonomics. Filed honestly in the v0.4 CHANGELOG entry rather than papered over.

[WaylandYang]

PR #211 closed half of this — forkd fork --live-fork now exists and plumbs MemoryBackend::MemfdShared through the local-boot path.

What's still open: there's no CLI verb that spawns via the daemon. The two existing pieces don't compose:

• forkd fork --live-fork boots Firecracker locally; the daemon doesn't track those processes.
• forkd snapshot --from-sandbox <id> --live hits the daemon's POST /v1/sandboxes/<id>/branch, which only knows about daemon-spawned sandboxes.

For a pure-CLI live-BRANCH workflow we'd need something like forkd sandbox spawn --tag X --live-fork (or extending forkd fork with a --via-daemon flag) that POSTs to /v1/sandboxes with live_fork: true. Existing daemon-aware verbs (ls, kill, rmi) confirm that pattern fits the CLI.

Also dropping the original "add to from-image / run" parts of the scope:

• from-image builds a snapshot TAG, but live_fork is per-spawn, not per-tag — no place to apply it.
• run is a one-shot that kills the child after the exec, so a live-BRANCH target wouldn't exist long enough to use.

Re-titling mentally to "Add daemon-side forkd sandbox spawn --live-fork CLI verb" for the remaining work.