fix: reduce Linux D-Bus method timeout

[gabref]

Why

This follows up on the Linux D-Bus timeout discussion from #14 .

A Linux connection_status() query can make several sequential D-Bus method calls. The existing two-second timeout applied independently to each call, rather than setting an overall deadline for the operation.
Consequently, an unresponsive NetworkManager or ModemManager service could cause the individual delays to accumulate while occupying a blocking worker thread.

These calls use the local system bus and primarily read cached service properties. Under normal conditions, they should complete within milliseconds, so a two-second allowance for every method call is unnecessarily high.

What changed

• Reduce the per-method D-Bus timeout from two seconds to 500 milliseconds.
• Document why local D-Bus reads are expected to complete quickly.
• Clarify that the timeout does not cover the initial D-Bus connection
  handshake or impose an aggregate deadline on the complete Linux query.
• Add a regression test for the configured timeout.

If a method call exceeds the timeout, the existing error handling remains
unchanged and the query uses the passive Linux fallback where applicable.

Tradeoffs and future work

D-Bus communication can take longer during unusual conditions, including:

• heavy CPU or I/O pressure;
• congestion in the D-Bus daemon or service queues;
• NetworkManager or ModemManager restarting or becoming unresponsive;
• suspend and resume transitions;
• heavily constrained virtualized or containerized environments.

The 500-millisecond timeout provides substantial headroom over normal
local D-Bus latency while reducing the effect of a stalled service.

This change intentionally does not refactor the D-Bus architecture.
A broader solution—such as an aggregate query deadline, connection reuse,
or a fully asynchronous implementation—would be worth considering if we
observe:

• legitimate calls regularly exceeding the new timeout;
• blocking-worker under concurrent requests;
• frequent polling where connection setup becomes measurable overhead;
• excessive aggregate latency despite the lower per-method timeout.

Without evidence of those conditions, lowering the timeout is a smaller
and proportionate improvement.