Fix Unicode GitHub file encoding

[davejohnson]

Summary

• encode GitHub Contents API writes as UTF-8 Base64 instead of browser btoa
• decode default-branch and managed-branch file reads as UTF-8
• use the same UTF-8 helpers for CNAME file content
• add regression coverage for Unicode writes and both read paths

Root cause

Hypervibe v0.1.4 generated deployment workflow and pull-request-template content containing characters such as —, smart quotes, and 🚧. The GitHub adapter passed the JavaScript string directly to btoa, which only accepts byte-range characters and threw InvalidCharacterError: Invalid character before the first repository-file write.

The read paths also used atob directly, returning mojibake for UTF-8 content and causing managed-file comparisons to drift after a successful write.

Impact

The failed HLS apply stopped safely before repository files, settings, secrets, bindings, or the applied contract marker converged. With this fix, generated Unicode workflows and templates round-trip correctly through GitHub's Base64 Contents API.

Verification

• regression test first failed on all three paths: Unicode write, default-branch read, and managed-branch read
• npm test -- --configLoader runner src/adapters/providers/github/__tests__/github.adapter.test.ts — 9 tests passed
• npm test -- --configLoader runner — 104 files, 818 tests passed
• npm run typecheck
• npm run build
• npm_config_cache=/private/tmp/hypervibe-npm-cache npm run prepublish-check
• git diff --check

Risks and follow-up

The change is limited to GitHub Contents API text encoding/decoding and preserves ASCII behavior. After merge, release a patch version, rebuild/restart the MCP, create a fresh HLS production plan, and resume the review-gated infrastructure apply. The failed plan must not be reused.