test(config_flow): prove a reconfigure entry really rebuilds the protocol transport (t35 F1)

The F1 test asserted the updated options; this closes the loop on the user
outcome — after the Reconfigure pairing, __init__._build_protocol_settings
returns settings (transport ON) pointing at the paired certificate under
.storage/nvidia_shield/ and at the address that just paired. That is why no
__init__.py change was needed: the reloaded entry already rebuilds the
transport from the persisted options + shared cert paths.

Verified: uvx --with pytest-asyncio pytest tests -q → 281 passed, 1 skipped;
uvx --with pytest-asyncio --with androidtvremote2 pytest tests -q → 282 passed;
uvx ruff check custom_components tests → clean.

tests/test_config_flow_ux.py

@@ -960,6 +960,15 @@ class TestProtocolReconfigure:
         assert hass.config_entries.reloaded_entry_ids == ["e1"]
         assert client.finished_codes == [FAKE_PAIRING_CODE]
 
+        # ...and the reloaded entry can really build the transport again: the
+        # settings point at the paired certificate + the address just paired,
+        # which is exactly what was impossible before reconfigure existed.
+        init = _integration_module()
+        settings = await init._build_protocol_settings(hass, entry)
+        assert settings is not None
+        assert settings["host"] == "10.0.0.9"
+        assert settings["certfile"].endswith("client.pem")
+
     async def test_reconfigure_host_correction_reopens_the_pin_step(
         self, tmp_path, monkeypatch
     ):