Fix Windows PowerShell 5.1 import failure from non-ASCII module source (#1603)

[eduardarbona (earbona23)]

Description

Import-Module Microsoft.Entra.Applications (and Microsoft.Entra.Beta.Applications) throws parser errors on Windows PowerShell 5.1 in 1.3.0, as reported in #1603.

Root cause

The shipped .psm1 is assembled by concatenating the per-cmdlet .ps1 source files and is written without a BOM. Several of the new AgentId / Blueprint / MCPServer source files contain non-ASCII characters (→, em/en dashes, ✓) in comments and in Write-Host / Write-Verbose strings.

Windows PowerShell 5.1 decodes a BOM-less file with the system ANSI code page rather than UTF-8, so each multi-byte character becomes a stray curly-quote that unbalances the surrounding string. The parser then fails with Missing closing ')' in expression and The string is missing the terminator, and the import aborts. PowerShell 7 reads BOM-less files as UTF-8, so CI and PowerShell 7 users never hit this.

Fix

• Replace the non-ASCII characters in the affected source files with ASCII equivalents (→→->, dashes→-, ✓→[OK]). ASCII parses identically under every encoding.
• Two Users cmdlet files carried the same non-ASCII-without-BOM hazard (a curly apostrophe in a HelpMessage); they are cleaned as well so the source tree is fully ASCII. Those two do not break the import, only garble help text, but they trip the same PSScriptAnalyzer rule.
• Add test/Entra/SourceFileEncoding.Tests.ps1, a Pester regression test that fails if any module/**/*.ps1 reintroduces non-ASCII bytes.

Testing

• Simulated the PS 5.1 read (decode source bytes as Windows-1252, then parse via the PowerShell AST parser): the original files produce the exact parser errors from the issue; the fixed files parse with zero errors.
• Invoke-ScriptAnalyzer no longer reports PSUseBOMForUnicodeEncodedFile on any of the changed files (16 findings removed, no new findings).
• New Pester test passes; verified it fails when a non-ASCII character is reintroduced.

Fixes #1603

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[learn-build-service-prod]

Learn Build status updates of commit 0b53622:

❌ Validation status: errors

Please follow instructions here which may help to resolve issue.

File	Status	Preview URL	Details
	❌Error		Details

• Line 0, Column 0: [Error: PSMD2Yaml_FileLoadFailed] Failed to load file: C:/LocalRun/W/qy1s-s/module/mapping/monikerMapping.json. PackageRoot, ReferenceTocUrl, and ConceptualTocUrl are required for every moniker. PackageRoot should be a valid relative path to docset root.

For more details, please refer to the build report.

Note: Your PR may contain errors or warnings or suggestions unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.

[eduardarbona (earbona23)]

Flagging that the red OpenPublishing.Build check is not caused by this PR.

The failure is PSMD2Yaml_FileLoadFailed on module/mapping/monikerMapping.json ("PackageRoot, ReferenceTocUrl, and ConceptualTocUrl are required for every moniker"). That file is not touched here — this PR only changes source encoding in 16 cmdlet files plus one test.

The same status is red on every recent open PR in this repo (#1601, #1572, #1529), so it looks like a docset configuration issue rather than per-PR validation. Happy to rebase if a fix lands.