fix: Resolve localized strings from the shipped file on every host

[tablackburn]

Summary

• Deletes the hand-written copy of every user-facing string that PowerShellBuild.psm1 kept in an
  inline data LocalizedData { ConvertFrom-StringData ... } block, leaving en-US/Messages.psd1
  as the only place a string is written.
• Asks Import-LocalizedData for en-US by name when the UI-culture lookup binds nothing, with
  -ErrorAction Stop on that fallback so a module genuinely missing its strings fails at import
  instead of blanking every message.
• Adds tests/LocalizedData.tests.ps1, which pins both the single source of truth and the
  behavior under a non-English UI culture on each supported host.

Closes #185.

The copy was reachable, not dead

Import-LocalizedData runs with -ErrorAction SilentlyContinue, so a lookup that resolves nothing
binds the inline copy and says nothing about it. The two supported hosts do not agree about when
that lookup misses. Probe module with en-US/Messages.psd1 (Source=en-US-file) and
de-DE/Messages.psd1 (Source=de-DE-file) beside a script that seeds $LocalizedData with
Source=inline-fallback and then runs the same splat the module used:

pwsh 7.5                               powershell.exe 5.1.26100.9168
  en-US -> en-US-file                    en-US -> en-US-file
  de-DE -> de-DE-file                    de-DE -> de-DE-file
  de-AT -> en-US-file                    de-AT -> inline-fallback
  fr-FR -> en-US-file                    fr-FR -> inline-fallback
  ja-JP -> en-US-file                    ja-JP -> inline-fallback

PowerShell 7 has a final en-US fallback: hide the en-US directory and fr-FR lands on
inline-fallback there too. Windows PowerShell 5.1 has no such fallback -- it walks the culture's
own parent chain and stops.

Against the real module on Windows PowerShell 5.1:

en-US: Keys=41 HasModuleLandingPageNotFound=True  requires Pester 6.0.0 or newer.
fr-FR: Keys=25 HasModuleLandingPageNotFound=False requires Pester 5.0.0 or newer.
ja-JP: Keys=25 HasModuleLandingPageNotFound=False requires Pester 5.0.0 or newer.

Sixteen of forty-one strings missing, and PesterVersionNotSupported still naming the pre-#182
floor. PowerShellVersion is '5.1' with CompatiblePSEditions = @('Desktop', 'Core'), and
non-English Windows installations are common, so this is reachable rather than theoretical.

One correction to the original report: a missing key does not throw. $null -f $arguments returns
an empty string on both hosts. The symptom was quieter and harder to diagnose -- a blank
WARNING: line from Build-PSBuildUpdatableHelp, and a bare ScriptHalted where
throw $LocalizedData.NoCertificateFound in IB.tasks.ps1 meant to explain that no signing
certificate was found.

en-US/Messages.psd1 itself was never the problem: the root Build task copies the whole source
tree, and Output/PowerShellBuild/0.8.2/en-US/Messages.psd1 is present after a build. Only the
lookup missed.

Why delete rather than resynchronize

Syncing the inline block and adding a text-comparison test would leave the duplication in place,
and a duplicate that a test keeps honest still has to be edited twice for every new string. The
comment it was written under -- "in case Import-LocalizedData is not available" -- guards against
nothing: Import-LocalizedData is in Microsoft.PowerShell.Utility and has shipped since
PowerShell 3.0, well below this module's 5.1 floor.

Deleting it alone would have left Windows PowerShell 5.1 on a non-English machine with no strings
at all, so the explicit en-US fallback replaces it. That fallback carries -ErrorAction Stop,
which is the "fail loudly" half: a module whose strings really are missing now fails at import
rather than emitting empty messages for the rest of the build.

Red before green

Invoke-Pester -Path ./tests/LocalizedData.tests.ps1 against the unfixed module:

Describing Localized string resolution
  [-] defines its user-facing strings in exactly one place
 Context Imported by pwsh.exe under a non-English UI culture
   [+] reports a string table from the probe
   [+] binds every string the module ships
   [+] binds each string to its shipped text
 Context Imported by powershell.exe under a non-English UI culture
   [+] reports a string table from the probe
   [-] binds every string the module ships
       Expected a collection ... with length 41, but got a collection ... with length 25.
   [-] binds each string to its shipped text
       Expected 'The resolved certificate has expired (NotAfter: {0}). ...',
       because [CertificateExpired] must match en-US/Messages.psd1, but got $null.
Tests Passed: 4, Failed: 3

After the fix, same command:

Describing Localized string resolution
  [+] defines its user-facing strings in exactly one place
 Context Imported by pwsh.exe under a non-English UI culture
   [+] reports a string table from the probe
   [+] binds every string the module ships
   [+] binds each string to its shipped text
 Context Imported by powershell.exe under a non-English UI culture
   [+] reports a string table from the probe
   [+] binds every string the module ships
   [+] binds each string to its shipped text
Tests Passed: 7, Failed: 0

The PowerShell 7 leg passes either way, which is exactly why the Windows PowerShell leg is there.
The drift guard is the part that fails on every platform, so a future inline copy is caught on
Linux and macOS runners too.

Test Plan

• ./build.ps1 -Task Test on Windows: 490 passed, 0 failed, 3 skipped (483/0/3 on main,
  plus the 7 new tests; the Windows PowerShell leg contributes 3 of them and is absent on
  Linux and macOS, where the file contributes 4).
• Analyze clean against the built module.
• The probe imports the built .psm1 rather than the manifest, so it does not depend on
  RequiredModules resolving against a child process's inherited PSModulePath -- which is
  what a Windows PowerShell child spawned from PowerShell 7 gets, and has nothing to do with
  which strings were bound.

Breaking Changes

None. Consumers on an English UI culture see no change; consumers on a non-English Windows
PowerShell 5.1 host stop getting stale and missing messages.

🤖 Generated with Claude Code

https://claude.ai/code/session_01U1Jhu7fgTRJq7LK5MuKteE

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[github-actions]

Test Results

    4 files  ± 0    769 suites  +9   2m 35s ⏱️ +16s
  496 tests +11    493 ✅ +11   3 💤 ±0  0 ❌ ±0 
1 967 runs  +23  1 900 ✅ +23  67 💤 ±0  0 ❌ ±0 

Results for commit 0d3a66a. ± Comparison against base commit a64ebc8.

♻️ This comment has been updated with latest results.