fix(examples): one identity per install, Wi-Fi Direct without Bluetooth, and peers that stay listed

[kivtxs]

The demo app is what everyone uses to smoke-test the SDK on phones. Driving it on two Androids for v0.28 turned up several demo bugs that made the SDK look broken when it wasn't. Each one below was reproduced, fixed and re-checked on the phones (Infinix NOTE 12 on Android 13, Seeker on Android 15).

Symptom on the phones	Cause	Fix
Every launch was a new person to its peers: contacts and encrypted sessions gone. A new keystore namespace each time.	generateUserId() minted a random profile per onboarding.	Fixed profile offline-demo; the SDK keeps its keys, so the address is stable across restarts.
The header showed an id the other phone never saw. Group rosters listed this device twice ("3 members" for two phones).	userId was the profile, while every event names the off1… address.	userId comes from localAddress() after start(). Rosters now read 2 and 2.
After a restart, an accepted contact read "53s ago" next to a live link.	A restored session raises no secure_session_established, so the contact never got hasSession or presence.	Seed sessionPeersRef from mlsListSessions() at start.
A live peer vanished from People about a minute after it appeared, so no request could be sent.	Neighbours were aged out after 60 s without a fresh neighbor_discovered. The SDK announces a peer once per link and reports neighbor_lost when it ends: Bluetooth after its reconnect attempts run out (about 4.75 min measured), Wi-Fi Direct when the stream closes.	No aging; rely on neighbor_lost. Measured: the peer stays listed past 2 min on both transports.
Onboarding refused to start with Bluetooth off, even with Wi-Fi Direct on.	It hard-required Bluetooth.	On Android with Wi-Fi Direct on, Bluetooth is optional.
Wi-Fi Direct never ran in the demo.	The config was BLE-only, and NEARBY_WIFI_DEVICES was never requested.	wifiDirect: { enabled: Platform.OS === 'android', autoAccept: true }. NEARBY_WIFI_DEVICES (13+) or fine location (≤12) is requested as optional.
The header pill said WIFIDIRECT while every send went over BLE.	It followed transport_switched, which the core also raises when a layer starts.	It follows dors_transport_selected / dors_transport_switched.
A connection request sat on "Pending" forever between two phones with wrong clocks.	No session can form (see #506).	Alert on KEY_PACKAGE_OUTSIDE_VALIDITY_WINDOW: "Check date and time".

Depends on

Typechecks and runs without these, but the Wi-Fi Direct and clock features need:

• fix(bindings): Android Wi-Fi Direct sends at once, rejoins its group, and starts from the config #505: Wi-Fi Direct starts from the config, and the permissions.
• feat(bindings): Android forms its Wi-Fi Direct group itself, without a system dialog #507: autoAccept forms the group.
• fix(protocol,mls): report a key package refused by this device's clock #506: the clock warning.

Validated on the phones

• Wi-Fi Direct, Bluetooth off, no location grant:
  • the group formed by itself in 26–55 s;
  • 1:1 chat 3/3 and 4/4 each way, about 100 ms;
  • after a restart: same address, contact Online again, chat 2/2.
• Bluetooth only (Wi-Fi off):
  • peer stayed listed past 2 min;
  • 1:1 chat 5/5 each way (median 225–290 ms);
  • group "Relief Crew": 2 members on both, 2/2 messages each way with receipts.
• Clocks 40 days apart: both phones showed the alert. 1 day apart: one did, and chat still worked, as fix(protocol,mls): report a key package refused by this device's clock #506 describes.
• tsc --noEmit: clean.