Generalize VCS-host coupling — harmonik should not assume GitHub (promote --pr hardcodes 'gh pr create')

[gregberns]

Framed as a PROBLEM to solve (not a prescribed design). Tracked in our ledger as hk-abo; supersedes an earlier narrow framing ('add a --provider azdo flag').

Problem

harmonik binds parts of its workflow to GitHub specifically, forcing users onto GitHub tooling. Clearest case: harmonik promote --pr opens pull requests by shelling to gh pr create (cmd/harmonik/promote_cmd.go, PR-mode is GitHub-CLI-only). Teams whose repos live on Azure DevOps (or GitLab/Bitbucket) cannot use PR-mode at all — gh does not talk to those hosts. We don't want harmonik to assume GitHub; it should support other VCS hosts/tooling.

Ask

1. Generalize the VCS-host coupling so PR/MR creation works across forges (GitHub via gh, Azure DevOps via az repos pr create, GitLab, etc.) — e.g. a provider abstraction selected by config or auto-detected from the remote URL. Exact shape is open for the owner to design; the requirement is simply 'not GitHub-only'.
2. Audit the rest of the system for other technology-specific bindings, not just PRs. Sweep anywhere harmonik assumes a particular host/tool/provider — remote-URL parsing, protected-branch conventions, auth assumptions, issue/work-item linking, etc. — and make the host a pluggable concern rather than baked in.

Context

• The consuming repos in our use are on Azure DevOps, so promote --pr is currently unusable for them.
• Prior related note also raised an agent-side helper (az repos pr create) as one option; the broader goal here is the generalized, provider-agnostic approach — owner's call on where the seam lives.