setFips() / setEngine do not evict ciphers cache

``` > require('crypto').getCiphers().length 130 > require('crypto').setFips(true) undefined > require('crypto').getCiphers().length 130 ``` but ``` > require('crypto').setFips(true) undefined > require('crypto').getCiphers().length 0 ``` Also (unverified): >`getCiphers` memoizes the cipher name list forever (`cachedResult(() => filterDuplicateStrings(_getCiphers()))`). When `setEngine(id, flags)` (also exported from this module) successfully loads an OpenSSL engine that registers additional ciphers, those new ciphers are not reflected in subsequent `getCiphers()` results because the cache is never invalidated. Similarly, on BoringSSL builds the cache is force-populated during module initialization via `conditionalAlgorithms` (the `'ChaCha20-Poly1305'` probe calls `getCiphers()`), freezing the answer before any user code runs. The sibling `_hashCache` helper in the same file explicitly clears on snapshot build / dynamic-link scenarios via `addSerializeCallback`; `getCiphers` has no such mechanism. > > `getHashes` returns a permanently-cached list from `_getHashes()` (via `cachedResult`). After a successful `setEngine(id, flags)` call (exported from this same module) loads an OpenSSL engine that registers new digest algorithms, `getHashes()` will continue to return the pre-engine snapshot. Downstream consumers — including this file's own `conditionalAlgorithms` gates for `cSHAKE*`/`SHA3-*`/ChaCha20-Poly1305 (evaluated once at module-load, so already locked in) and any external callers using `crypto.getHashes()` — will not observe engine-provided hashes. Contrast with the sibling `getHashCache` (line 81–91) which is explicitly designed to be refreshed.