Fix MCP and Companion version identities

[davejohnson]

What

• read the Hypervibe MCP runtime version from the package metadata for both the MCP initialize handshake and hv_upgrade
• identify the macOS Companion MCP client with its own bundle version, with an honest development fallback
• give the installer an explicit COMPANION_VERSION input while preserving the current combined release-number default
• document and test the version identity boundary

Why

The built MCP package was 0.1.3, but its MCP handshake still identified the server as 0.1.0. The Companion client identity was hardcoded to the same stale value. These identities now come from their respective artifacts rather than hardcoded strings.

Release impact

This does not bump a version or split the current release pipeline. Under the existing vX.Y.Z workflow, the MCP package and Companion still share a release number by default, but each reports its own authoritative identity. A future independent Companion release can pass COMPANION_VERSION explicitly.

Checks

• npm test — 104 files, 810 tests
• npm run typecheck
• npm run build
• direct compiled MCP stdio handshake — initialize and hv_upgrade both report 0.1.3
• npm run prepublish-check
• swift test — 42 tests
• swift build -c release --product HypervibeCompanion
• bash -n scripts/build-macos-installer.sh
• git diff --check