fix: eliminate activation confirmation race

[davidvornholt]

What changed

• Register the activation confirmation watcher on the temporary directory before creating the canary.
• Filter removal events to the expected canary path.
• Add a regression test covering immediate canary removal after watcher setup.

Why

The activation process previously created the canary before registering its watcher. A fast controller could observe and delete the canary during that gap, leaving the activation process waiting until confirm_timeout and then rolling back a deployment that had already been confirmed.

Watching the parent directory before exposing the canary removes that gap. It also avoids trying to register a watcher on a file that may already have been deleted.

Validation

• cargo test --all-targets
• cargo clippy --all-targets -- --deny warnings
• cargo fmt --check
• nix flake check --show-trace