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.

Locate the crypto module file containing cachedResult, setFips, setEngine, conditionalAlgorithms, and the getHashCache helper at lines 81–91. Trace how getCiphers and getHashes are cached and how existing cache-refresh behavior works; done means successful FIPS or engine changes are reflected in subsequent algorithm-list results.