fix: sort parameter keys before iterating to ensure deterministic output in wiki documentation

[oWretch]

Summary

Fixes #1284

Build-PolicyDocumentation was iterating $parameters.Keys (unordered hashtable enumeration) in multiple output-producing locations. PowerShell does not guarantee stable key enumeration order across runs, causing parameter entries within markdown table cells and CSV/JSONC exports to shuffle between runs — even when nothing had changed — producing large, noisy wiki diffs.

Changes

Added | Sort-Object to each affected foreach loop so parameters are always emitted in alphabetical order.

The issue identified 4 locations. On review, a 5th output-producing location was also found in Convert-ParametersToString.ps1 (used for CSV JSON blob and JSONC text exports) with the same bug:

File	Line	Output type
Scripts/Helpers/Out-DocumentationForPolicySets.ps1	169	Markdown table cells
Scripts/Helpers/Out-DocumentationForPolicyAssignments.ps1	406	Markdown table cells
Scripts/Helpers/Convert-PolicyResourcesDetailsToFlatList-Documentation.ps1	249	Flat list → markdown
Scripts/Helpers/Convert-PolicyResourcesDetailsToFlatList-Documentation.ps1	478	Flat list → markdown
Scripts/Helpers/Convert-ParametersToString.ps1	11	CSV JSON blob + JSONC text (broader than issue)

Other $parameters.Keys iterations in the codebase (Confirm-*, Build-*, Merge-*, etc.) are internal computation only — order there does not affect any output and was left unchanged.

Design note: Sort-Object vs ordered hashtable

An [ordered] hashtable was considered as an alternative. It was rejected for the following reasons:

Ordered hashtables preserve insertion order, not alphabetical order. Parameters are accumulated by merging from multiple policies/policy sets across several files. To achieve alphabetical order with [ordered], you would also need to sort the source keys at every merge/insertion point — effectively the same work, just spread across more files.

The source data is inherently unordered. Parameters originate from Azure API JSON responses with no guaranteed key order. There is no natural "meaningful" order to preserve — alphabetical is the right semantic choice, and Sort-Object makes that intent explicit at the point of output.

Sort-Object at the output point is:

• Defensive — correct regardless of how upstream data was populated
• Minimal blast radius — 5 one-line changes vs changes across more files and data models
• Explicit — the alphabetical intent is clear at the location where it matters
• Future-proof — remains correct even if data construction code changes later

[apybar]

Will test and confirm