An already-open output tab keeps showing an execution that was cleared

[Chirag6722]

OutputFileSystemProvider declares the change event the FileSystemProvider interface asks for, but nothing ever fires it:

private readonly _onDidChangeFile = new vscode.EventEmitter<vscode.FileChangeEvent[]>();
readonly onDidChangeFile = this._onDidChangeFile.event;

readFile is therefore called once per URI and VS Code has no reason to ever call it again.

To reproduce:

1. Run a command, click it in the sidebar to open its output.
2. Leave that tab open.
3. Run TruthLog: Clear History.

The sidebar empties, but the open tab still shows the full output of an execution that is no longer in history. readFile would now return the "no longer in history (history was cleared or trimmed)" message, which is the honest answer, and it is the answer you get if you close the tab and somehow reopen the URI. It just never gets asked. The same applies when an entry is dropped by the maxEntries trim while its tab is open.

Nobody is going to lose data over this, but a stale tab is a slightly awkward thing for this particular extension to have, since the whole pitch is that what you are looking at is ground truth and not a stale summary of it.

Firing Changed (or Deleted) for the affected URIs from store.onDidChange would make VS Code re-read. That means tracking which ids currently have a document open, or just firing for every id that left the store on that change.