Ubuntu 26: is_enable() returns before NetworkManager assigns the bridge IP, causing bind() failures

[tarkus1]

On Linux (tested on Ubuntu 26), `is_enable()` in `crates/unlocker-helper/src/ops/linux.rs`
calls `NM.ActivateConnection` over D-Bus and returns `Ok(())` as soon as NM
acknowledges the request. `ActivateConnection` is fire-and-forget — NM brings
up the interface, assigns the `10.42.0.0/24` address, and starts dnsmasq
asynchronously, after the D-Bus call already returned.

Whatever calls `is_enable()` proceeds immediately to bind the DNS/HTTPS
listeners to the bridge IP via `bridge_ip()`, which fails with
`Cannot assign requested address (os error 99)` because the address isn't
assigned yet. This is 100% reproducible on Ubuntu 26 for me.

Notably, `integration_tests::test_hotspot_lifecycle` already knows about this
gap — it polls `bridge_ip()` for up to 15s after `is_enable()` returns before
asserting the hotspot is up. That same wait just isn't in the production
`is_enable()` path.

Fix: poll `bridge_ip()` inside `is_enable()` (same logic as the integration
test) before returning `Ok(())`. Happy to submit this as a PR if useful.