shareReplay with refCount: stale replay on resubscribe versus leaked subscription — which trade-off for cached HTTP streams?

Integration boundary: Angular HTTP wrapper + RxJS shareReplay

I am wrapping HTTP calls in a shared service where multiple components subscribe to the same response stream, and I am using shareReplay to avoid duplicate requests. The documented config-object form, shareReplay({ bufferSize, refCount, windowTime }), forces a decision I cannot resolve from the docs alone.

With refCount: false, the underlying subscription appears to stay alive after the last subscriber unsubscribes, which risks a leaked subscription for long-lived services. With refCount: true, the source resubscribes when a new subscriber arrives, but the internal ReplaySubject reportedly still replays previously buffered values first — so a component expecting a fresh fetch may receive stale data before (or instead of) a new request.

Assume RxJS 7.x; I am aware the overloads and defaults differ from pre-6.4 versions, so answers should target the config-object signature. There also seems to be no built-in "reset buffer on resubscribe" option, leaving custom reset logic as the only middle ground.

1. Is the stale-replay-on-resubscribe behavior with refCount: true guaranteed by the documented contract, or an implementation detail that could change?
2. For a cache-like HTTP wrapper, which combination of bufferSize, refCount, and windowTime is the intended idiom to get "replay while active, refetch after idle" semantics?
3. If custom reset logic is required, what is the canonical operator composition that clears the buffer without re-implementing reference counting?