[BUG] Pip updates fail through Agent broker: Global is sent as Machine

Start by examining the Pip inventory in src/UniGetUI.PackageEngine.Managers.Pip/Pip.cs to see how PackageScope.Global is assigned. Then review BrokerRequestBuilder.cs to understand the mapping from Global to Machine. The Agent's Pip command builder in the devolutions-gateway repository shows what scopes are supported. The fix involves distinguishing between interpreter base-site and user-site installations and adjusting the scope mapping accordingly. Test with a per-user Python installation having both base-site and user-site packages.

Please confirm these before moving forward

• I have searched for my issue and have not found a work-in-progress/duplicate/resolved issue.
• I have tested that this issue has not been fixed in the latest (beta or stable) release.
• I have checked the FAQ section for solutions.
• This issue is about a bug (if it is not, please use the correct template).

UniGetUI Version

2026.3.0 (latest stable)

Windows version, edition, and architecture

Windows 11 x64, build 26200

Describe your issue

Observed behavior

With UniGetUI 2026.3.0 and Devolutions Agent 2026.3.0, the broker is reachable and its policy is loaded. Pip updates fail before pip starts:

Broker package manager 'Pip' does not support scope 'Machine'.

This affects unrelated Pip packages and is distinct from #5273, where the broker itself is unavailable.

Root cause

• Pip inventory currently labels installed and updatable distributions PackageScope.Global without determining their actual installation scheme.
• BrokerRequestBuilder maps Global to broker Machine for every manager. The Agent advertises only User for Pip and rejects Machine/elevated Pip requests.
• Simply changing every request to User is not correct: the Agent adds --user, which installs into the Python user-site. A per-user Python installation can also have packages in its separate interpreter base-site. On this machine both schemes occur under the same Python 3.10 interpreter.
• The Agent resolves python.exe from the target user PATH rather than receiving a bound interpreter identity. The client also sends the Pip source URL although the Agent Pip builder rejects explicit source URLs. A scope-only change would therefore still not provide reliable updates.

Expected behavior / proposed fix

1. Discover and retain the Python interpreter and installation scheme for each Pip distribution. Do not treat Pip Global as proof of OS-wide Machine scope.
2. Define broker semantics for interpreter base-site versus Python user-site. For a per-user interpreter, run base-site updates under the same non-elevated user without --user; use --user only for confirmed user-site packages. Bind discovery and execution to the same validated interpreter. Do not allow a client-supplied arbitrary executable path to bypass broker policy.
3. Keep true Machine/elevated Pip operations unsupported until the Agent can select and validate a trusted system-wide Python and its imported pip modules. Do not elevate a user-writable Python installation.
4. Represent default PyPI without an unsupported explicit source URL, and validate/authorize any custom index in the broker protocol.
5. Until end-to-end support exists, reject unsupported Pip broker operations before queueing with an actionable capability message. Do not silently fall back to local execution when the broker is required.

Suggested regression tests

• Base-site package in a per-user Python: same interpreter, no elevation, no --user, no duplicate user-site installation.
• User-site package: same interpreter, --user.
• Different Python on PATH: never update a different interpreter from the one inventoried.
• Machine/elevated Pip: rejected unless a trusted system-wide interpreter is explicitly supported.
• Default versus custom package source, and mixed bulk updates with other managers.

Steps to reproduce the issue

1. Install Python for the current Windows user and install a package into its interpreter base-site (ordinary python -m pip install <package>). Optionally install another package with --user into the separate user-site.
2. Install UniGetUI 2026.3.0 and Devolutions Agent 2026.3.0, enable a working Agent broker, then refresh Pip updates.
3. Start an update for either Pip package. The operation fails at broker validation with the same Machine-scope message, before pip runs.

UniGetUI Log

Broker package manager 'Pip' does not support scope 'Machine'.

Package Managers Logs

No pip process/output: the broker rejects the request before invoking the package manager.

Relevant information

Relevant source paths (release v2026.3.0):

• UniGetUI Pip inventory: https://github.com/Devolutions/UniGetUI/blob/v2026.3.0/src/UniGetUI.PackageEngine.Managers.Pip/Pip.cs
• UniGetUI scope translation: https://github.com/Devolutions/UniGetUI/blob/v2026.3.0/src/UniGetUI.PackageEngine.AgentBroker/BrokerRequestBuilder.cs
• Agent Pip capabilities and command builder: https://github.com/Devolutions/devolutions-gateway/blob/v2026.3.0/crates/now-package-broker/src/server/responses.rs and https://github.com/Devolutions/devolutions-gateway/blob/v2026.3.0/crates/now-package-broker/src/command_builder/pip.rs
• UniGetUI local Pip update behavior: https://github.com/Devolutions/UniGetUI/blob/v2026.3.0/src/UniGetUI.PackageEngine.Managers.Pip/Helpers/PipPkgOperationHelper.cs

Screenshots and videos

No response