drm: ship the wake in the CI deb, and assert the artifact on both package paths

Three findings from the round on the wake-gate commits, all the same shape: the
gate made "what was asked for" and "what was produced" diverge, and two places
still trusted the first.

CI built the unattended-wayland deb with `--features ...,drm` and then packaged
it with `--skip-cargo`. build.py appends `drm-wake` for `--drm`, but skipping
cargo means whatever that explicit line compiled is what ships, so the deb had
no wake code in it at all while being named and documented as the variant that
has it. The feature list has to be complete on the line that actually builds.

The marker assertion that catches exactly this class only guarded one of the two
packaging paths. `build_deb_from_folder` asserts that the staged binary carries
the libdrmtap dlopen path before it takes the unattended-wayland name; the
flutter path did not, and `--skip-cargo` reaches that one. A stock binary could
therefore be packaged under a name that conflicts with and replaces the stock
package, and then never capture. Hoisted the check to module level and called it
from both, before the bundle is renamed.

And the security doc described the synthetic input injection as an unconditional
property of a drm build. It is behind its own compile feature and a runtime
option, which is exactly what an operator auditing the deb needs to know.

.github/workflows/drm-capture.yml

@@ -338,7 +338,9 @@ jobs:
       - name: Build the unattended-wayland deb
         shell: bash
         run: |
-          cargo build --locked --lib --release --features hwcodec,flutter,unix-file-copy-paste,drm
+          # drm-wake must be listed HERE: build.py adds it for --drm, but the next line passes
+          # --skip-cargo, so build.py never rebuilds and whatever this line compiled is what ships.
+          cargo build --locked --lib --release --features hwcodec,flutter,unix-file-copy-paste,drm,drm-wake
           python3 ./build.py --flutter --drm --skip-cargo
 
       # build.py exits 0 on some inner failures, so assert the artifact instead of trusting the status,