Daemon records neither the Volume cut's stop nor a requested removal, so status reads both as a copy not serving#2792

What happens

Two Machine-local operations leave a copy in a state status cannot tell from a failure:

• The Volume move's cut: stop_behind_ingress stops the old copy with record=false (core/crates/ployzd/src/machine/local_machine/container.rs, the stop_checked call), so the copy stays rotation In, runtime Exited (143 from the Docker stop), stopped: false. From #2781 on, ployz status names it exited with code 143 with a ployz logs hint for the stop-to-start window of the move. The docs describe that window as downtime, so the row is true, but its words and hint suggest a crash.
• A direct copy removal (sdk::agent::remove_one to cleanup::user_remove to retire): the copy is Out and running while the proxies unlist it and the drain runs (a few seconds), with no Deployment record. For a single-copy Service status reads Serving 0 of 1 copy. <machine> draining for those seconds.

What should happen

The owning Machine records what it did (bet 6, Machine-local authority): a cut's stop as stopped, and a requested removal as a rotation or flag the reads can see. Status then needs no inference and no timer for either.

Scope

A daemon change, out of #2781's scope by design (PROTOCOL_MAJOR 1, no daemon change). Found in the review of #2781 (Reviewers A and B).