fix(kms): recover from DRM master handoff failure

[francocarballar]

Closes #2635

Summary

• Detect missing DRM authentication on the primary KMS device before compositor readiness.
• Abort startup so systemd retries the session handoff with a fresh DRM descriptor.
• Preserve secondary/render-only device behavior.
• Fix existing Clippy warnings required by CI.

Root cause

When the greeter still owns DRM master during startup, Smithay can initialize the device as unprivileged. cosmic-comp previously continued startup and announced readiness, leaving the graphical session on a black screen.

Validation

• cargo +stable fmt --all -- --check
• cargo +stable clippy --all-features -- -D warnings
• cargo +stable check --all-targets
• cargo +stable check --no-default-features
• cargo +stable check --features debug
• cargo +stable check --features profile-with-tracy
• cargo +stable check --features profile-with-tracy-gpu
• cargo +stable test --all-features
• git diff --check

All automated checks passed.

Hardware validation on the affected Dell Latitude 3520 has not been performed yet because reproducing the DRM handoff can make the graphical session unavailable.

Contributor declarations

• AI-assisted code was disclosed in the commit message, as required by the repository template.
• I understand the changes and will respond to review comments.
• The commit includes a DCO sign-off with git commit -s.

[Drakulix]

This is not the correct solution to this issue. Rather what needs to be fixed is the greeter keeping the drm master state.

Which was already done (but not yet tagged) in #2382