Investigate: heap corruption / OOM from rapid TLS context churn in monitorNodeCAs during reconnect cycles

## Summary

Under aggressive replication reconnect cycling, `tls.createSecureContext` is called repeatedly inside `monitorNodeCAs`. This has been observed correlating with heap corruption and OOM in production environments.

## Current assessment

Believed to be a symptom of the crash-loop / full-copy OOM cycle (see #286) rather than a standalone bug, but the TLS churn may be an independent contributor worth isolating. Nathan and Devin have looked at this but root cause is not confirmed.

## Technical detail

- `monitorNodeCAs` calls `tls.createSecureContext` on every reconnect attempt
- Under a crash-loop this can happen at high frequency, cycling memory for TLS contexts
- Observed correlating with `heap corruption` and `OOM` process crashes

## Relation to other issues

- #286: full-copy crash loop (may be the primary cause of the reconnect churn)
- This issue: whether the TLS churn itself is an independent OOM vector

## Next step

Confirm whether adding debouncing/caching to `monitorNodeCAs`'s `createSecureContext` calls reduces or eliminates the heap corruption independent of the full-copy fix.