docs: add getPinningDiagnostics fix to CHANGELOG [3.5.14]

Author: ivol

CHANGELOG.md

@@ -9,6 +9,7 @@
 - Shaded and relocated the BouncyCastle dependency (`io.approov.internal.bouncycastle`) to prevent version collisions for consuming applications.
 - **Android NetworkInterceptor Pinning**: Replaced the OkHttp `CertificatePinner`-based pinning approach with a new `ApproovPinningInterceptor` registered as a `NetworkInterceptor`. Pins are now read from `Approov.getPins()` at TLS-handshake time during each request rather than eagerly at `initialize()`. This eliminates the root cause of a cold-start hang where `notifyPinChangeListeners()` → `getPins()` → `refreshConfig()` blocked the JS Promise on a `CountDownLatch` with no timeout while waiting for a queued `FetchConfig` network request. A bounded handshake cache (10 entries) avoids redundant pin checks on repeated connections. The `PinChangeListener` interface is deprecated but retained for source compatibility.
 - **Android initialize() Unblocked**: As a consequence of the NetworkInterceptor pinning change above, `ApproovService.initialize()` now resolves its JavaScript Promise immediately after SDK initialization without any blocking `getPins()` network call. Previously, on cold start with no cached dynamic configuration, initialization could block the JS bridge for 2–26 seconds depending on network conditions.
+- **Android getPinningDiagnostics Fix**: `isPinnerPresent` was incorrectly evaluated against `client.certificatePinner()`, which always returns `CertificatePinner.DEFAULT` now that pinning lives in `ApproovPinningInterceptor`. The diagnostic now inspects `client.networkInterceptors()` for `ApproovPinningInterceptor`, correctly reporting pinning presence under the new architecture.
 
 ## [3.5.13] - 2026-04-12
 - **Initialization Comment Bridging**: Extended the public React Native `ApproovService.initialize()` API and `ApproovProvider` to accept an optional nullable `comment` parameter and forward it to the native Approov SDK. This enables advanced SDK comments such as explicit `reinit...` runtime reinitialization and initial-call `options:...` configuration while remaining optional for normal app startup.