feat(#11281): bring up the wifi hotspot and pairing

[paulpascal]

Closes #11281 (android half). The webapp half is medic/cht-core#11450.

Brings up the local-only hotspot and the local server behind it, so a CHW's phone can pair with a supervisor's.

The host starts a LocalOnlyHotspot and serves over TLS with a certificate generated per session and held in the Android keystore. The QR carries ssid, password, ip, port and the certificate fingerprint. The peer scans it, joins, and verifies the host against that fingerprint before pairing counts as done, so a network that merely has the right name is not enough.

A platform limit shapes this, worth knowing before reading the diff. LocalOnlyHotspot needs API 26 while our minSdk is 21. So HOSTING is gated at 26 and reported through a bridge availability method, the way mrdt_available() and sms_available() already do it, rather than failing silently later. JOINING works on everything we support: WifiNetworkSpecifier from API 29, addNetwork below it.

The keystore is the other unknown. Not every device can serve TLS from a keystore-backed key, so generation self-tests with a real loopback handshake and fails immediately with a clear reason instead of dying later at an odd moment.

Everything crossing the bridge is a stable code, never a sentence, since prose cannot be translated. All 13 failure codes have a p2p.error.* key in cht-core.

Known gaps, deliberate: there is no mid-session monitoring, so a hotspot that drops after pairing goes unnoticed. That belongs to #11282, where a transfer can actually be interrupted, and it is noted there. No wdio either, since pairing needs two devices.

Draft. make test was green at this tip, about 50 flavours with 0 failures, and the lint gate is clean. But it has NOT been exercised on two physical phones yet, which is the only real test for this. Putting it up so the shape can be reviewed while that happens.