refactor: remove device Pairing feature entirely (issue #645) (#650)

* refactor: remove device Pairing feature entirely (issue #645)

- Delete Pairing.kt model + pairing API endpoints (get/approve/revoke/clear)
- Delete PairingScreen/PairingViewModel + PairingCodeEntryScreen/ViewModel
- Remove NavKeys, ScreenRegistry drawer entry, Navigation.kt entry + Landing pairing button
- Remove pairing string resources (en + ko); keep connect_* config-parse strings
- Keep Telegram onboarding pairing_id flow (separate concept, per issue)
- Fix related doc comments + remaining test reference

* test: fix racy CONNECTED read in gated-mode WS test (issue #635 test)

testGatedMode_attemptsTicketFetchWithoutBareCookie asserted CONNECTED
immediately after the server-side onOpen latch fired, racing the client
handshake (WsListenerImpl sets CONNECTED on receipt of the 101). Await the
real status transition via connectionStatus.first{==CONNECTED} like the
other connect tests do. No product behavior changed.

---------

Co-authored-by: M57 <Hy4ri@users.noreply.github.com>

app/src/main/java/com/m57/hermescontrol/data/model/Pairing.kt

@@ -1,30 +0,0 @@
-package com.m57.hermescontrol.data.model
-import kotlinx.serialization.Serializable
-
-@Serializable
-data class PairingResponse(
-    val pending: List<PairingItem>,
-    val approved: List<PairingItem>,
-)
-
-@Serializable
-data class PairingItem(
-    val platform: String,
-    val user_id: String? = null,
-    val username: String? = null,
-    val display_name: String? = null,
-    val code: String? = null,
-    val created_at: String? = null,
-)
-
-@Serializable
-data class PairingApproveRequest(
-    val platform: String,
-    val code: String,
-)
-
-@Serializable
-data class PairingRevokeRequest(
-    val platform: String,
-    val user_id: String,
-)