ZE FileSystemProvider `stat` function throws an authentication error for correct credentials

[hohy]

Describe the bug

When calling the stat function of the Zowe Explorer FileSystemProvider while logged out of the Authentication Service, a FileSystemError is thrown even though correct credentials are provided during the authentication prompt. The error indicates an authentication failure, but subsequent stat calls with the same parameters succeed without error.

To Reproduce

1. Open VSCode
2. Configure zosmf profile but DO NOT log in to Authentication Service
3. Call ZE FS provider with code similar to this

try {
  await vscode.workspace.fs.stat(
    vscode.Uri.parse(`zowe-ds:/${profileName}/${dsn}?fetch=true`)
  );
} catch (error) {
  vscode.window.showErrorMessage(error.stack);
}

4. Zowe Explorer prompts for login to the Authentication Service
5. Enter correct credentials
6. ZE displays Login to authentication service successful dialog.
7. Despite the successful login, the stat function throws the following error:

Error (FileSystemError): Rest API failure with HTTP(S) status 401 This operation requires authentication.

8. Repeating the same stat call with the same parameters returns the correct result without error.

Expected behavior
The initial stat call should succeed if correct credentials are provided during the authentication prompt, even if the user was not previously logged in. No error should be thrown in this scenario.

Screenshots

Desktop (please complete the following information):

• OS: macOC
• Zowe Explorer Version: 3.2.0
• (Optional) Zowe CLI Version:
• (Optional) Do you have secure credentials enabled?
• (Optional) Are you using a custom credential manager?

Additional context

[github-actions]

Thank you for creating a bug report.
We will investigate the bug and evaluate its impact on the product.
If you haven't already, please ensure you have provided steps to reproduce the bug and as much context as possible.

[traeok]

This behavior is seen because the current file system implementations do not retry requests after a user has acknowledged an authentication prompt. The opt-in enhancement, proposed in #3726, resolves this scenario and could serve as a general application for multiple functions in the filesystem.

I've captured this as test criteria in the enhancement to ensure this is resolved as part of the implementation.

From offline discussions, we've gathered that the risk for an extender performing the retry is currently much greater compared to Zowe Explorer doing it, as only Zowe Explorer knows the result of the authentication prompt. The prompt result is not properly forwarded to the extender through the thrown error, so the extender does not know whether the user has successfully re-authenticated. Throwing a more explicit error for when a user cancels the authentication dialog mitigates that risk and helps developers proceed until the retry functionality is available within Zowe Explorer.