Discuss trusted first-time setup and configuration-change approval behavior for aks-mcp

AKS Desktop preconfigures the built-in aks-mcp server. During first-time setup, Electron may display a confirmation dialog indicating that the MCP configuration is changing or that new tools are being added.

We would like the initial, known aks-mcp configuration to work without requiring user intervention. However, simply hardcoding aks-mcp as always approved would also suppress important dialogs for future configuration changes.

Problem
There are two different scenarios:

Initial trusted setup

AKS Desktop adds the canonical, built-in aks-mcp configuration.
Requiring confirmation creates unnecessary friction because this server is shipped and managed by AKS Desktop.
Subsequent configuration changes

The command, arguments, access level, enabled components, environment variables, or discovered tools may change.
These changes may affect security or expand available capabilities.
Users should be informed and may need to explicitly approve them.
If approval is bypassed solely by checking that the server name is aks-mcp, we lose the ability to request user approval when its configuration or tool set changes.

**Discussion**

Can AKS Desktop distinguish between:

1. Seeding the exact trusted built-in aks-mcp configuration for the first time.
2. Reapplying the same trusted configuration.
3. A user modifying the configuration.
4. The application changing security-sensitive fields.
5. aks-mcp exposing new or changed tools.

**Possible approaches include:**

- Trusting only an exact canonical configuration or configuration hash.
- Recording the last approved configuration and tool inventory.
- Silently approving only the initial host-managed setup.
- Showing confirmation when security-sensitive fields or available tools change.
- Adding provenance metadata to distinguish host-managed configuration from user-defined configuration.
- Providing a dedicated Electron API for installing a trusted built-in MCP server rather than bypassing the generic confirmation flow.

**Expected behavior**

1. The first installation of the canonical, host-provided aks-mcp configuration should not require user interaction.
2. Unchanged trusted configurations should not repeatedly prompt.
3. User-defined servers named aks-mcp must not automatically become trusted.
4. Material configuration or tool-inventory changes should require approval.
5. Other MCP servers should continue using the existing confirmation flow.

**Security considerations**
Trust should not be based only on the server name. Otherwise, an arbitrary or modified executable could use the aks-mcp name to bypass confirmation.

The trust decision should verify the source and expected configuration while preserving user consent for later capability changes.

Start by tracing Electron's existing generic MCP confirmation flow and the built-in aks-mcp setup path. Define how the Electron API or trust record distinguishes the exact host-managed configuration from user changes, and verify the expected behavior: initial and unchanged trusted setup is silent, while material configuration or tool changes still require approval.

Written by the indexing model from the issue text.