Dummy `main.rs` files can result in confusing binaries which do nothing

We're using cargo chef to build a test Docker image.

In our acceptance tests, we were not building some of the required test binaries from another crate. (This is an unstable cargo feature -Z bindeps, which you can workaround using an empty integration test.)

So the binary we were copying was built by cargo chef cook in an earlier stage, with an empty main.rs. We spent some time trying to work out why it wasn't producing any output in our tests.

Here is how we were originally using cargo chef:
https://github.com/ZcashFoundation/zebra/blob/7681da374dde00022a0efadce811e3a7a18a3fb4/docker/Dockerfile#L110

And here's the changes we needed to get the new test working:

Incomplete change - just copy the (fake) binary:
https://github.com/ZcashFoundation/zebra/pull/6550/files#diff-f34da55ca08f1a30591d8b0b3e885bcc678537b2a9a4aadea4f190806b374ddcR117

Workaround - build the binary for the tests:
https://github.com/ZcashFoundation/zebra/pull/6550/files#diff-e7a58077f5761507dda333fd31c1f456f16a05d7a090175883709edf64ecce2cR1-R9

This seems like something worth documenting.
Can you also make the fake binaries log a message explaining why they don't do anything?

Edit:
Or can you delete them after that stage has been built?

Start with the Dockerfile section linked around line 110 and compare the incomplete and workaround changes in pull request 6550. Trace where the dummy main.rs binaries are produced, then document the empty-binary behavior and establish whether logging a message or deleting the binaries is the intended resolution.