Resolve TypeTable race in live test RunspacePool

[vidai-msft]

Move type loading from Update-TypeData -AppendPath in AzError.ps1 to TypesToProcess in Az.Accounts.psd1. The -AppendPath path triggers ProcessTypeFiles() which performs a non-atomic Read-Clear-Rebuild on the shared RunspacePool TypeTable, corrupting engine ETS types (e.g. Job.State) when multiple workers concurrently import Az.Accounts.

TypesToProcess is loaded via Import-Module Bind(updateOnly=true) which never calls TypeTable.Clear(), eliminating the race. This is the idiomatic PowerShell pattern, consistent with Az.Sql and Az.Functions.

Also re-enables the Assert-AreEqual on Job.State in FileTests.ps1 that was commented out as a workaround.

Description

Mandatory Checklist

• Please choose the target release of Azure PowerShell. (⚠️Target release is a different concept from API readiness. Please click below links for details.)

  • General release
  • Public preview
  • Private preview
  • Engineering build
  • No need for a release

• Check this box to confirm: I have read the Submitting Changes section of CONTRIBUTING.md and reviewed the following information:

• SHOULD update ChangeLog.md file(s) appropriately
  • Update src/{{SERVICE}}/{{SERVICE}}/ChangeLog.md.
    • A snippet outlining the change(s) made in the PR should be written under the ## Upcoming Release header in the past tense.
  • Should not change ChangeLog.md if no new release is required, such as fixing test case only.
• SHOULD regenerate markdown help files if there is cmdlet API change. Instruction
• SHOULD have proper test coverage for changes in pull request.
• SHOULD NOT adjust version of module manually in pull request

[azure-client-tools-bot-prd]

Thanks for your contribution! The pull request validation has started. Please revisit this comment for updated status.

[Copilot]

Pull request overview

This PR fixes a race condition in the PowerShell RunspacePool's shared TypeTable that occurs when multiple workers concurrently import Az.Accounts. The root cause was Update-TypeData -AppendPath in AzError.ps1, which performs a non-atomic Read-Clear-Rebuild on the TypeTable. The fix moves type loading to the idiomatic TypesToProcess manifest entry in Az.Accounts.psd1, consistent with how Az.Sql and Az.Functions handle their type data.

Changes:

• Moved type loading from Update-TypeData -AppendPath in AzError.ps1 to TypesToProcess in Az.Accounts.psd1 to eliminate the concurrency race
• Re-enabled two Assert-AreEqual assertions on $t.State in FileTests.ps1 that were previously commented out as a workaround for the race condition

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File	Description
src/Accounts/Accounts/Az.Accounts.psd1	Added TypesToProcess = 'Accounts.types.ps1xml' to module manifest for safe, idiomatic type loading
src/Accounts/Accounts/StartupScripts/AzError.ps1	Removed the Update-TypeData -AppendPath call that caused the TypeTable race condition
src/Storage/LiveTests/Storage.Management/FileTests.ps1	Re-enabled two Assert-AreEqual "Completed" $t.State checks that were commented out as a workaround