Repair lockfile pins corrupted by the release version bump

[Sev7eNup]

Cutting 1.1.2 replaced every "version": "1.1.1" in the tree instead of just the top-level one, so six transitive entries across the three lockfiles declare a version that does not exist and does not match the tarball they resolve to:

Lockfile	Entries
nodepilot-desktop	abbrev, object-keys, picocolors
nodepilot-docs-ui	picocolors
nodepilot-ui	cookie, picocolors

npm ci rebuilds the tree from the lockfile and cross-checks each tarball's own version, so this breaks reproducible installs on any clean install.

The six pins are restored by hand rather than by regenerating — a regeneration would drag unrelated transitive updates into the same commit and hide the actual repair.

Guard against the cause. The corruption comes from a blanket text replace during the release bump; nothing would have stopped it recurring on the next version that collides with a real dependency version. Test-DeploymentTemplates.ps1 (already run on both PowerShell 5.1 and 7 in CI) now asserts that every entry resolving to a registry tarball carries the version that tarball's filename states. It renames npm's empty-string root key before parsing, because Windows PowerShell 5.1 cannot build a PSCustomObject with an empty property name and fails the whole document otherwise.

Also restores two em dashes in TopBar.tsx committed as double-encoded UTF-8 (â€"). Comments only, so nothing behaved differently — but the same round-trip would silently mangle a translated string.

Verification

• Contract script passes on PS 5.1, and fails with the exact entry named when the corruption is reintroduced.
• Repo-wide scan finds no other double-encoded source.

Closes #119
Closes #112