shareReplay with takeUntil: need explicit buffer reset on destruction signal

Goal: ensure that when migrating a small RxJS‑based application version‑by‑version without downtime, any cached values from a shareReplay stream are cleared as soon as the destruction signal for the old version emits.

Constraint: the takeUntil operator completes the source observable, but shareReplay retains its replay buffer until the internal refCount drops to zero, which may keep the old version’s source subscribed longer than desired.

Uncertainty: whether it is sufficient to rely on the refCount behavior to discard the buffer, or whether a public reset() method on the shared replay subject should be exposed to forcefully flush replayed values.

Questions: Should we implement a reset() method to manually clear the replay buffer on destruction? Can we safely depend on refCount reaching zero after takeUntil to avoid stale data? What are the trade‑offs between manual reset and refCount‑based cleanup regarding migration safety and memory usage?