revealFileInOS may ignore the passed URI or pick additional URIs from Explorer selection depending on UI state

[n-gist]

During extension development, an issue was encountered where commands.executeCommand('revealFileInOS', uri) may ignore the passed URI and use the current Explorer selection instead. For example: (1) an item is selected in the Explorer view, and (2) the command is invoked without switching to another view/editor, by using an extension tree view title context menu.

In general, the provided URI argument is ignored when the Explorer View is focused, has a selection, and the provided URI is not part of that selection.

According to discussions in issues such as #110869 and #232522, revealFileInOS appears to be an internal command tied to the Explorer view, and extensions may be expected to implement their own revealing approach.

However, the following code was found to use revealFileInOS with an explicit URI, relying on it to reveal the specified resource:

• https://github.com/microsoft/vscode/blob/main/extensions/copilot/src/extension/log/vscode-node/requestLogTree.ts
• https://github.com/microsoft/vscode/blob/main/extensions/typescript-language-features/src/typescriptServiceClient.ts
• https://github.com/microsoft/vscode/blob/main/extensions/git/src/commands.ts
• https://github.com/microsoft/vscode/blob/main/src/vs/workbench/contrib/chat/browser/agentPluginActions.ts
• https://github.com/microsoft/vscode/blob/main/src/vs/workbench/contrib/chat/browser/actions/chatPluginActions.ts
• https://github.com/microsoft/vscode/blob/main/src/vs/workbench/contrib/chat/browser/actions/createPluginAction.ts
• https://github.com/microsoft/vscode/blob/main/src/vs/workbench/contrib/chat/browser/aiCustomization/aiCustomizationManagement.contribution.ts

These consumers may reveal incorrect paths if an unrelated item is selected in the Explorer during execution.

It seems that one of the following approaches may be needed:

• Fix revealFileInOS (getMultiSelectedResources) so an explicitly passed URI is always respected, while preserving the existing multi-selection behavior where needed.
• Change the listed consumers to avoid revealFileInOS and instead use a revealing mechanism that operates directly on the specified URI.
• Introduce a separate command for revealing explicitly specified URIs that is independent of Explorer selection and view focus state, also accessible by extensions.

[n-gist]

After further analysis, it appears that the behavior of revealFileInOS cannot be changed to correctly support the listed consumers. Even if it were modified to always respect the passed URI, it would still need to use the Explorer selection when invoked from the Explorer context menu in order to preserve multi-selection support.

This makes introducing a separate command, such as revealUriInOS, that strictly operates on the passed URI, and switching existing consumers to use it instead of revealFileInOS, a more appropriate solution. It would also provide extensions with a dedicated, recommended command for revealing a specific URI in the OS.