feat: implement macOS connectivity detection

[polw1]

Summary

Adds macOS support for connection_status() using Apple’s Network framework.

• implement the macOS backend with NWPathMonitor
• map connectivity, metered, constrained, and transport status into the existing plugin types
• treat only nw_path_status_satisfied as connected: true
• document the macOS path-status semantics in code comments and README
• add test coverage for macOS path-status handling and connection-type priority

Closes #8

Test plan

• cargo check
• cargo test --workspace --lib
• npm run standards

[polw1]

Creating and destroying an NWPathMonitor on every call feels fragile, especially with a fixed timeout. Apple’s API delivers path updates through callbacks scheduled on a dispatch queue, so treating the first frontend request as a synchronous one-shot query felt like the wrong model.

NWPathMonitor is better treated as a long-lived monitor than as a synchronous status getter.

So i changed the implementation to create the monitor once, caches the latest status, and returns that cached value from plugin calls.

I also start the monitor during plugin setup so the system has a chance to receive the first path update before the frontend makes its first real request, instead of making that request responsible for initializing the monitor.

[velocitysystems]

@polw1 Changes look good. On further evaluation, since the monitor is stored in a static OneLock<T> the drop trait will never actually execute. It's probably best we remove the drop trait and add an inline comment noting the singleton is never cancelled.

[velocitysystems]

Hi @polw1. This PR can now be rebased again master.

[velocitysystems]

Thanks @polw1. Did a final review but just found one thing we may want to fix.

[velocitysystems]

The wifi > wired > cellular priority here is the plugin's own heuristic over independent nw_path_uses_interface_type probes, each of which only reports whether the path uses that interface at all.

But types.rs documents connection_type as "the preferred/primary transport as determined by the OS," and the Windows backend honors that by classifying the single preferred ConnectionProfile. On a docked laptop with both Wi-Fi and Ethernet active, both probes return true and this reports Wifi, even though macOS service-order typically routes over Ethernet — so the two platforms disagree on the same contract.

[polw1]

Good catch. I missed that we have nw_path_enumerate_interfaces, whose docs say the interfaces are enumerated in order of preference.

I’ll use that instead.