Answer Network.Status on iOS from one long-lived path monitor

[ngunyimacharia]

The iOS Network.Status starts a new NWPathMonitor on every call, waits up to 2s for its first path, and cancels it. That has two costs:

• Every call pays a round trip to the network daemon before the monitor delivers anything. Apps that check status per request (ours calls it on every API request) pay that on each one, on a synchronous bridge call.
• A timeout is reported as connected: false. If the first path is slow, a device on working wifi is told it is offline, and apps that gate writes on it refuse them.

This change keeps one monitor alive for the life of the process and answers from its latest path. Only the first call can arrive before any path does, so only that call waits (0.5s). If nothing has arrived by then, it returns the usual shape plus an error key, the same way the Android implementation already reports a failure, instead of claiming the device is offline.

The response shape is unchanged for every existing field, so $status->connected still works. The README documents the error case.

This long-lived observer has shipped in our app since its v0.7.0 release, as a patch on nativephp/mobile (see NativePHP/mobile-air#507, closed in favour of this plugin). The error fallback is the only new part.

Not tested here: no Swift toolchain on the machine this PR came from, and the plugin's suite is PHP only.