android-v0.6.2

Fix guests seeing a raw disconnect instead of "host stopped" on stop

Two bugs, both from 0.6.0's move to a hard Process.killProcess() on
stop:

1. HostForegroundService.onDestroy() called nearbyHost.stop() BEFORE
   telling the server to notify guests. A Nearby peer's connection is
   tunneled over Nearby Connections itself, so tearing that transport
   down first killed the tunnel before the server ever got a chance to
   push 'hostStopped' through it — a Nearby guest only ever saw a raw
   disconnect. Reordered: notify first, then tear down Nearby.

2. Even with that fixed, the Kotlin side blocking on the HTTP response
   only proved server.js's handler function had returned quickly, not
   that guests actually received anything — sock.send() returning
   doesn't confirm delivery. /api/local/host-control now waits (up to
   500ms per socket, in parallel) for each socket's own 'close'
   confirmation before responding, turning the Android-side wait into
   one tied to an actual completion signal. Bumped the Kotlin-side
   timeout from 1.5s to 2.5s to comfortably cover that.

Verified in-browser with a real WebSocket guest connection: the
'hostStopped' message arrives 2ms before the socket's close event, and
the whole host-control round-trip (which now waits for that close)
completed in 8ms.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>