feat: replace svcl with native Core Audio

[Ayerdi]

Summary

• Replace the SoundVolumeCommandLine (svcl.exe) runtime/install dependency with an in-process Windows Core Audio COM backend.
• Preserve the existing WindowsEndpoint + LogitechGHub detection model and the current PowerShell project structure.
• Enumerate render endpoints directly through IMMDeviceEnumerator / IMMDevice, including Active, Disabled, NotPresent, and Unplugged states.
• Read endpoint identity from native Windows properties while keeping the current internal row shape so the installer/runtime do not need a structural rewrite.
• Read the default render endpoint per Windows audio role and set Console, Multimedia, and Communications through the isolated IPolicyConfig compatibility boundary.
• Verify all three roles after every switch and keep one bounded retry.
• Treat native enumeration/read failures as Unknown, preserving the rule that an unknown state never changes the output.
• Remove the NirSoft download/hash/extraction path from clean installs and delete a stale legacy svcl.exe during upgrades.
• Update verifier, README, security notes, technical sources, changelog, and maintenance guidance.
• Fix the language guard's false positive for the valid English word submenu, and explicitly allow plural PowerShell helper nouns where the helper returns a collection.

Why this PR is stacked

This is intentionally based on #9 (agent/repository-standard-v1.2.5) so the diff stays focused on the native audio backend instead of mixing in the repository-standardization work already under review. After #9 merges, this PR can be retargeted/rebased onto main.

Validation

Validated on a Windows GitHub Actions runner (windows-latest):

• PowerShell parser: pass
• Pester: 42/42 passed
• Embedded C# Core Audio bridge (Add-Type) compilation: pass
• Active-code/documentation check for the removed external audio-control dependency: pass

The repository's normal validate workflow is also green on the current PR head:

• repository quality: pass
• English canonical language guard: pass
• deterministic release build: pass
• secret scan: pass
• PowerShell syntax: pass
• PSScriptAnalyzer: pass
• Pester: pass

Compatibility / risk

Endpoint enumeration, endpoint state, properties, and reading default endpoints use documented Windows Core Audio/MMDevice APIs. Windows does not expose a documented public API for changing the system default endpoint; this PR keeps that operation isolated behind IPolicyConfig::SetDefaultEndpoint, treats HRESULT failures as errors, and verifies the resulting default endpoint for all three roles instead of trusting the setter.

CI cannot validate real headset/dongle behavior. Before merge I recommend a manual ON → OFF → ON test on:

1. a device using WindowsEndpoint (for example the previously tested Jabra), and
2. Logitech PRO X 2 using the LogitechGHub fallback,

checking that both the headset and fallback outputs are actually selected as expected.

[Ayerdi]

Review note before merge: Set-AudioOutput keeps the existing bounded retry when the first native setter call completes but the post-switch role verification does not match. If Set-CoreAudioDefaultRenderDevice itself throws on the first attempt, the current function exits before reaching that retry. CI cannot exercise this path because the runner has no real headset/dongle setup. I would harden this by catching the first setter error, still performing the role verification, and allowing the one existing retry before failing. This is intentionally called out while the PR remains draft so it is not lost before the manual hardware test.