[upstream #16998] #16998: Block TTS cache reads in other tabs during a remote clear #325

Local review finding on LibreChat-AI#16998 (local:afaf5b5:L-003, recorded in the reviewctl ledger; not a GitHub thread).

When one tab announces a TTS cache clear or logout, other tabs advance their epoch and stop writing, but they do not block reads. A tab can still openTTSCache() and match() an entry while the announcing tab's caches.delete is in flight, or after that delete failed in the announcing tab and only that tab retries it.

Impact is limited. The reading tab is still showing the same signed-in account, so it can only read audio cached for that account. A new account reaches that tab only through openTTSCacheWrites, which runs after authentication. That function advances the epoch and reruns the purge, but it does not retry another tab's failed delete.

Proposed fix: on a remote notice, mark the delete pending in the receiving tab too, so its next openTTSCache() deletes before it reads. Alternatively, scope the cache name to a per-session id so the next account never opens the departed session's cache.

Deferred under the stack policy for cross-tab coordination edge cases on LibreChat-AI#16998.