`CertificateVerificationHTTPSHandler.https_open()` rebuilt `self._context` from the Certificate Manager on every request, throwing away any context the caller passed to the constructor. This broke the legacy `ssl_cert` fallback for hosting service accounts. When a stored certificate does not match the server's hostname, `_build_ssl_context_from_ssl_cert()` deliberately returns a context with that certificate loaded and `check_hostname` turned off. That context was replaced with a strict one that had neither, so those connections would fail verification. The handler now records whether the caller supplied a context, and rebuilds the context only when it did not. Contexts that the handler built itself from `hostname` and `port` are still rebuilt from the request URL, so a redirect to another server continues to use the right certificates. Testing Done: - Added a test covering an explicit context surviving `https_open()`, which failed before this change. - Added a test covering a context built from the `hostname` and `port` arguments. - Ran unit tests for `reviewboard.certs` and `reviewboard.hostingsvcs`.