Unify signing identity resolution across all transport callers

Background

Every command that calls HttpTransport must pass a SigningIdentity resolved against the actual target remote URL, not the repo's default hub URL. The two can differ — e.g. when a named remote points to staging while the repo's [hub] url is localhost:1337.

The current codebase has inconsistent patterns across callers. ls-remote had a concrete bug (HTTP 401 on staging) because it called get_signing_identity(root) before resolving the remote URL. Fix shipped in feat/test-merge-6. The remaining callers need auditing.

Callers of fetch_remote_info and their current pattern

Also spotted

• proposalType returned by the hub still uses state_merge — legacy value not covered by the alias cleanup (migration 0070 only handled mergeStrategy). Needs its own migration and enum cleanup.

Proposed phases

Phase 1 — Audit all callers Read each caller, verify whether remote_url is forwarded correctly to get_signing_identity. Document any that resolve against the wrong hostname.

Phase 2 — Fix callers For each broken caller: resolve URL first, then call get_signing_identity(root, remote_url=url). Add regression tests matching the pattern in test_cmd_ls_remote.py::TestSigningIdentityForwarding.

Phase 3 — proposalType canonical cleanup Add migration 0071 to rename state_merge → merge (and any other state_* / domain_* proposal type values). Update enum, service, MCP tools, and templates.

Phase 4 — Integration test Wire test that runs muse ls-remote, muse fetch, muse pull, muse push against a local hub instance with a non-default hub URL and asserts no 401s.