Unit-test the strict (release) daemon resolver — verify_bundled_binary against a Contents/MacOS fixture

[hellno]

Problem

The release daemon resolver — resolve_binary() + verify_bundled_binary() in crates/deckard-signerd/src/supervise.rs (the #[cfg(not(feature = "dev-signerd-bin"))] path, finding C1) — is the code that actually ships, yet it has zero automated coverage. Every dev/test/QA flow (just run/qa/demo, cargo test) builds with dev-signerd-bin and exercises the loose resolver (env → sibling → $PATH) instead. release.yml ships source-only and never builds the .app. That gap is how #134 shipped: the strict verified-sibling path was never run by anything but a human double-clicking the bundle.

Proposal

Add unit coverage for the strict provenance gate so its contract is locked and documented:

• Test verify_bundled_binary() against a temp fixture laid out like Contents/MacOS/ (a sibling daemon file in a us-owned, non-group/world-writable dir):
  • accepts a regular, us-owned, 0o755 file in a 0o755 us-owned parent;
  • rejects a missing file, a symlink, a group/world-writable file (mode & 0o022 != 0), and a group/world-writable parent dir.
• This requires compiling the strict path in a test. Since the crate-level guard forbids dev-signerd-bin in release only, a default-feature cargo test -p deckard-signerd (no dev-signerd-bin) should compile the strict resolve_binary; confirm the test module can target it (may need a small #[cfg] arrangement so both resolvers are reachable under test).

Optional, heavier (separate, not required here)

A bundle-check recipe (or a nightly/manual job) that runs just bundle and asserts Contents/MacOS/deckard-signerd exists and passes the same provenance predicate the resolver uses — catching a recipe-level regression directly. Not CI-cheap (needs cargo-bundle + a release GPUI build), so keep it out of the default Definition of Done; a tiny opt-in recipe is enough.

Follow-up from #134 / PR #143.