Workspace trust: update dialog and status bar item styling and fix command state handling

[ndoschek]

What it does

Follow-up to #16809

• Workspace Trust Dialog and Styling Improvements:
  • Replace ConfirmDialog with a new styled WorkspaceTrustDialog component featuring better visual hierarchy with shield icon, proper spacing, and improved layout
  • Update status bar item to use prominent styling when in restricted mode
  • Update dialog message to acknowledge that workspace trust is not yet fully implemented in Theia
• Command State and Folder Management:
  • Fix getWorkspaceTrust() to return current trust state immediately if already resolved, instead of waiting for initial promise (fixes stale values in quick input)
  • Add removeFromTrustedFolders() method to remove workspace from trusted folders when user selects "Don't Trust" via command

How to test

1. Open a workspace that is not in the trusted folders list
2. Verify the workspace trust dialog appears with the new styling and updated text description
3. Click "No, I don't trust the authors" and verify the status bar shows the "Restricted Mode" item with prominent styling
4. Run command Workspaces (either via status bar item or command palette): Manage Workspace Trust and toggle trust states
5. Verify that the current indicator is always up-to-date and when untrusting a workspace, it is removed from the trusted folders preference properly

Follow-ups

https://github.com/eclipse-theia/theia/tree/GH-16872

Breaking changes

• This PR introduces breaking changes and requires careful review. If yes, the breaking changes section in the changelog has been updated.

Attribution

Review checklist

• As an author, I have thoroughly tested my changes and carefully followed the review guidelines
• User-facing text is internationalized using the nls service (for details, please see the Internationalization/Localization section in the Coding Guidelines)

Reminder for reviewers

• As a reviewer, I agree to behave in accordance with the review guidelines

[colin-grant-work]

I'm not sure exactly what would be best for this message. The current state of the feature, as I understand it, is basically that its efficacy is restricted to (some parts of) the plugin system. That means that if all plugins behave nicely and check workspace trust before doing things that could be dangerous, it actually works as intended. But if some plugin automatically runs e.g. some compilation task with a malicious definition without first checking trust, we wouldn't stop it, and I think VSCode would.

So the sense we want to communicate is that the answer to the question is not irrelevant, but saying 'no' may not have all the effects that the user would expect.

But maybe we should just hook up workspace trust in the task and debug systems to stop those systems from running in untrusted workspaces, and then I'll stop hemming and hawing :-).

[colin-grant-work]

I think there is a problem with this method:

    protected isWorkspaceInTrustedFolders(): boolean {
        const workspaceUri = this.workspaceService.workspace?.resource; // <--- Could refer to workspace file.
        if (!workspaceUri) {
            return false;
        }
        const trustedFolders = this.workspaceTrustPref[WORKSPACE_TRUST_TRUSTED_FOLDERS] || [];
        const caseSensitive = !OS.backend.isWindows;
        return trustedFolders.some(folder => {
            try {
                const folderUri = new URI(folder).normalizePath();
                return workspaceUri.normalizePath().isEqual(folderUri, caseSensitive); // <----- Workspace file would never be equal to any folder.
            } catch {
                return false; // Invalid URI in preferences
            }
        });
    }

[colin-grant-work]

That can cause oddities like this:

The file shouldn't appear there - workspace trust should be a function of all of the folders in the workspace and whether they're trusted or not.

[colin-grant-work]

We also end up with workspace files in the preferences: only folders should go there.

[ndoschek]

As disussed offline, I created a follow up for this part: #16887

[colin-grant-work]

The changes to the messages and styling look reasonable.

I think, however, that there are significant issues with the interpretation of workspace trust in saved / multiroot workspaces in the existing implementation that need to be addressed.

[ndoschek]

Thanks for the thorough review, Colin. As discussed offline I totally agree that there are important parts that are still missing, but I created the follow-up issues for those, all tracked under the umbrella issue #12318.