fix: pre-initialize mTLS flag from in-memory key state to handle TLS session resumption in Wear OS onboarding

When setting up a Wear OS device the mTLS certificate-selection screen
was silently skipped if TLS session resumption occurred, causing the
watch to register without a client certificate and the server to return
HTTP 400.

Root cause: isTLSClientAuthNeeded in TLSWebViewClient is only set inside
onReceivedClientCertRequest. When the onboarding WebView reuses the main
app's existing TLS session (abbreviated handshake), the server never
issues a new CertificateRequest so the callback never fires — even with
ssl_session_tickets disabled on the server, because Android's Chromium
network stack maintains its own in-process TLS session cache.

Fix: add TLSWebViewClient.preInitializeTLSClientAuthState() which checks
whether a private key is already loaded in KeyChainRepository (non-null
getPrivateKey()). A non-null key means the phone is currently connected
to an mTLS-protected instance, so isTLSClientAuthNeeded is pre-set to
true before the WebView starts loading. If the app was force-stopped
first, in-memory state is cleared and no TLS session can be resumed, so
onReceivedClientCertRequest fires naturally on the fresh handshake.

ConnectionViewModel.init calls preInitializeTLSClientAuthState() before
emitting the auth URL so the navigation layer sees the correct value.

Also adds two unit tests to ConnectionViewModelTest covering the
in-memory key present and absent cases.

Author: smhc

app/src/main/kotlin/io/homeassistant/companion/android/onboarding/connection/ConnectionViewModel.kt

@@ -116,6 +116,12 @@ internal class ConnectionViewModel @VisibleForTesting constructor(
 
     init {
         viewModelScope.launch {
+            // Pre-set the mTLS flag before emitting the auth URL. If the phone is currently
+            // connected to an mTLS-protected instance, the private key is already loaded in
+            // memory. The onboarding WebView will reuse the live TLS session (session resumption)
+            // so onReceivedClientCertRequest never fires — pre-setting the flag ensures the
+            // Wear OS cert-selection screen is not silently skipped.
+            webViewClient.preInitializeTLSClientAuthState()
             buildAuthUrl(rawUrl)
         }
     }

app/src/main/kotlin/io/homeassistant/companion/android/util/TLSWebViewClient.kt

@@ -39,6 +39,36 @@ open class TLSWebViewClient(private var keyChainRepository: KeyChainRepository)
     private var key: PrivateKey? = null
     private var chain: Array<X509Certificate>? = null
 
+    /**
+     * Pre-initializes [isTLSClientAuthNeeded] from the current in-memory key state to handle
+     * TLS session resumption.
+     *
+     * Normally [isTLSClientAuthNeeded] is set when [onReceivedClientCertRequest] fires during
+     * a full TLS handshake. However, when TLS session resumption occurs (the WebView reuses an
+     * existing session from the same process), the server does not issue a new
+     * `CertificateRequest`, so [onReceivedClientCertRequest] is never called — even if the
+     * server requires a client certificate.
+     *
+     * This is the root cause of the Wear OS onboarding mTLS failure: the main app WebView
+     * establishes a TLS session while the user is connected; the onboarding WebView immediately
+     * resumes it, bypassing the callback that would reveal the mTLS requirement to the
+     * navigation layer.
+     *
+     * The fix checks whether the repository already holds a loaded private key in memory. A
+     * non-null key means the phone is currently connected to an instance that required a client
+     * certificate, so [isTLSClientAuthNeeded] is pre-set to `true`. If the app was force-stopped
+     * first (clearing in-memory state) no TLS session can be resumed either, so
+     * [onReceivedClientCertRequest] will fire naturally on the fresh handshake.
+     *
+     * Must be called **before** the WebView starts loading (i.e. before the URL is emitted).
+     * Idempotent: if the flag is already `true` (set by a real handshake) this is a no-op.
+     */
+    fun preInitializeTLSClientAuthState() {
+        if (!isTLSClientAuthNeeded) {
+            isTLSClientAuthNeeded = keyChainRepository.getPrivateKey() != null
+        }
+    }
+
     private fun getActivity(context: Context?): Activity? {
         if (context == null) {
             return null

app/src/test/kotlin/io/homeassistant/companion/android/onboarding/connection/ConnectionViewModelTest.kt

@@ -417,4 +417,32 @@ class ConnectionViewModelTest {
         assertEquals("class java.lang.UnsatisfiedLinkError", error.rawErrorType)
         verify(exactly = 1) { connectivityCheckRepository.runChecks(rawUrl) }
     }
+
+    @Test
+    fun `Given a private key already loaded in memory when initializing then isTLSClientAuthNeeded is pre-set to true`() = runTest {
+        every { keyChainRepository.getPrivateKey() } returns mockk()
+
+        val viewModel = ConnectionViewModel(
+            "http://homeassistant.local:8123",
+            webViewClientFactory,
+            connectivityCheckRepository,
+        )
+        advanceUntilIdle()
+
+        assertTrue(viewModel.webViewClient.isTLSClientAuthNeeded)
+    }
+
+    @Test
+    fun `Given no private key in memory when initializing then isTLSClientAuthNeeded remains false`() = runTest {
+        every { keyChainRepository.getPrivateKey() } returns null
+
+        val viewModel = ConnectionViewModel(
+            "http://homeassistant.local:8123",
+            webViewClientFactory,
+            connectivityCheckRepository,
+        )
+        advanceUntilIdle()
+
+        assertFalse(viewModel.webViewClient.isTLSClientAuthNeeded)
+    }
 }