When the server encounters a rollback affecting any authoritative collection, it currently clears the entire in-memory cache (DSS and CSS) rather than just the affected namespace, forcing a full reload from disk.

This is a regression from 8.0 behavior, where a rollback could be traced to a specific namespace (one collection per namespace), allowing targeted cache invalidation. With the move to a single collection holding metadata for all namespaces, we can no longer identify which namespace triggered the rollback, so the whole cache is dropped as a fallback.

Also, the CSR is not getting cleared if only the oplog c entries that maintain the CSR roll back. This is a correctness issue that would leave the CSR in a state that doesn't match what is on the disk. The contents in CSR might be ahead of what is on the disk.

To fix, we will do the following:

1. Add a server parameter to decide between clearing and not clearing the CSS on live rollback.
2. In the triggers to clear the CSR/DSR, include rollback of the oplog c entries for CSR/DSR maintenance.
3. Ensure that there is enough FTDC and logs to diagnose and RCA if a customer hits this issue.

Then follow up with more tickets for a longer-term solution. Consider the following for follow-up tickets:

1. SERVER-132384 - Observability and testing that demonstrates what this issue might look like if seen in production.
2. SERVER-132573 - The long-term fix for this issue. Among possible solutions, we can consider never clearing the CSR or tracking the namespaces that can be selectively be cleared.
3. SERVER-132590 - Prove and test that clearing the CSR is not really needed. This builds confidence that if needed, we can flip the server parameter introduced by SERVER-130703.