When a script runs in PowerShell 7 using the AD service-account credential, modules installed in the standard module directories cannot be discovered

Hi,
After upgrading an existing PowerShell Universal installation from 2026.2.3.0 to 2026.3.0.0, I encountered what appears to be a regression involving module discovery when combining the built-in PowerShell 7 environment with an alternate execution credential.

Configuration
The affected scripts use:

• Environment: PowerShell 7, configured with -Type "PowerShell7"
• Execution → Credential: an AD service account
• Modules installed under the standard machine-wide Windows module directories

The original environment configuration was:

New-PSUEnvironment -Name "PowerShell 7" -Variables @('*') -Description "The PowerShell 7 version included with PowerShell Universal." -Type "PowerShell7"

Actual behavior
When a script runs in PowerShell 7 using the AD service-account credential, modules installed in the standard module directories cannot be discovered.
For example:

Import-Module TOPdeskPS
fails with:

The specified module 'topdeskps' was not loaded because no valid module file was found in any module directory.
Importing TOPdeskPS by its full path causes its dependency to fail instead:

Import-Module 'C:\Program Files\WindowsPowerShell\Modules\TOPdeskPS\0.1.6\TOPdeskPS.psd1'
Result:

The required module 'PSFramework' is not loaded. Load the module or remove the module from 'RequiredModules' in the file 'C:\Program Files\WindowsPowerShell\Modules\TOPdeskPS\0.1.6\TOPdeskPS.psd1'.
If I import both PSFramework and TOPdeskPS using their complete paths, they load successfully. This confirms that the modules themselves work in this host, but automatic module discovery does not.
The problem only occurs with the combination:

PowerShell 7 + AD service-account execution credential
The same modules load successfully when using Windows PowerShell 5.1 or when running with another execution account.

Workaround
Adding the standard module directories explicitly to the PowerShell 7 environment resolves the issue:

New-PSUEnvironment -Name "PowerShell 7" -Variables @('*') -Description "The PowerShell 7 version included with PowerShell Universal." -Type "PowerShell7" -PSModulePath @(
'C:\Program Files\PowerShell\Modules'
'C:\Program Files\WindowsPowerShell\Modules'
'C:\Windows\System32\WindowsPowerShell\v1.0\Modules'
)
After applying this configuration, I tested several affected scripts using the AD service account and they all completed successfully without any script-specific workarounds.

Expected behavior
The normal machine-wide PowerShell module directories should remain available when a PowerShell 7 job is started using an alternate execution credential, without requiring them to be added explicitly to every environment.
Could you confirm whether this is a known regression in 2026.3.0.0, possibly related to the changes around PowerShell versions or process hosting?
I can provide sanitized PSModulePath output or relevant logs if needed. Also, tell me if this needs to be filed as a Github issue!