Upgrade to dbus-rs 0.9.12

[saschanaz]

Fixes https://bugzilla.mozilla.org/show_bug.cgi?id=2061689

Please double check with tests before merging.

This builds, but I'm not quite sure it works as tests fails locally on my environment, even on the current master branch. And there's no CI with tests, so I'm not even sure whether the tests ever passed. Maybe some documentation about the testing environment would be nice.

[zang3tsu]

Verified on real hardware (Arch-based CachyOS, rtkit 0.14, KDE Plasma, rustc 1.97.1): this PR behaves identically to master on the RtKit path.

test	master	this PR
it_works	pass	pass
test_linux_api	pass	pass
test_remote_promotion	pass	pass
it_works_in_different_threads	fail (EBUSY)	fail (EBUSY, identical)

The local failures look environmental rather than dbus-related:

• Without rtkit installed, every dbus-path test panics — the graceful skip-guard only exists for the non-dbus build.
• With rtkit, it_works_in_different_threads spawns 32 threads doing ~6 promotions each, which trips rtkit-daemon's burst rate limiting ("Device or resource busy") — and the throttle window then poisons any test that runs shortly after, so full cargo test runs produce cascading order-dependent failures even on master. Running tests individually with ~45s spacing is deterministic.

So: no regression attributable to the dbus-rs 0.9.12 upgrade. Follow-up ideas: a dbus-build skip-guard mirroring the non-dbus one, and capping the stress test's thread count below rtkit's burst limit.

[saschanaz]

Fwiw only test_linux_api passes on Bazzite.

[zang3tsu]

That matches the request-budget arithmetic: rtkit-daemon grants 25 requests per 20s window per user, master's suite issues 168 by construction, and test_linux_api only needs one — which is why it's the survivor. #48 restructures the suite to a measured 16 requests so a cold cargo test passes deterministically. If you get a chance, could you check whether that branch passes fully on Bazzite?