emrg: https→ssh fallback for blocked github.com:443 in evolution workspace

[argszero]

Problem

The evolution workspace self-heal (#489/#490) clones https://github.com/argszero/emrg.git and the saturation-halt auto-resume (#531) polls via git ls-remote origin. On networks that block github.com:443 (observed on the packaged host: git pull hangs ~75 s then fails with "Failed to connect to github.com port 443", while ssh -T git@github.com and api.github.com work), every clone/pull/push/ls-remote fails:

• the self-heal clone never succeeds → workspace missing → cycles skipped
• the saturation auto-resume never fires → halted handlers stay halted forever
• pull/push in the evolution loop fail against an https origin

Fix

Add narrow HTTPS→SSH fallback helpers in git_utils.py and wire them into the scheduler:

• https_to_ssh_url() — converts https://github.com/owner/repo.git → git@github.com:owner/repo.git (rejects non-github/non-https URLs)
• is_git_connection_error() — recognizes connection-type git errors only (never auth/404/repo-specific, which switching would not fix)
• git_origin_url() — reads the raw origin URL
• EvolutionHandler._ensure_origin_reachable() — one probe per handler lifetime (git -c http.connectTimeout=4 ls-remote); on a connection failure switches the origin to the SSH URL so subsequent pull/push/ls-remote keep working
• _clone_workspace() — clone retried via SSH on connection-type failure; http.connectTimeout=10 makes blocked https fail in seconds instead of hanging
• _remote_advanced() — falls back to the SSH URL when ls-remote origin fails with a connection error (covers the halted-before-probe case)

Tests

14 new tests (575 → 589): pure-function coverage for the URL conversion and error classification (positive + negative states), origin-switch/keep/no-switch-on-404, one-shot probe idempotency, clone https→ssh retry, and the _remote_advanced SSH fallback. Mutation-checked: removing the fallback logic turns the new tests red.

Verified: uv run pytest tests/ 589 passed, import check + emrg --help OK.

[argszero]

✅ LGTM — cycle 20260808-092759

Reviewed the full diff (+483/−32, 7 files) and verified locally:

• 589 tests pass on the PR head (checked out in a worktree; master baseline 575 + 14 new) — the claimed count is exact
• import check + emrg --help OK; PR CI run 31232698787 SUCCESS (actionlint gate included)
• Verification logic sound (#455/#461/#464): is_git_connection_error tested in both positive (connect/refused/timeout) and negative (auth/404/empty) states; https_to_ssh_url positive (with/without .git) + negative (ssh URL, gitlab, enterprise host, file://, empty); git_origin_url returncode check is reliable for remote get-url (unlike security find-certificate -a, #464)
• Narrow blast radius: origin switch only on connection-type errors; auth/404 never trigger it; one-shot probe per handler lifetime; clone https→ssh retry; _remote_advanced SSH fallback covers the halted-before-probe case
• Doc-count guard (#511): Agent.md + README.md 575→589, README.cn stale 548→589 corrected

This directly addresses the network-restricted environment observed on this host (github.com:443 hangs while SSH works).

[argszero]

✅ LGTM — cycle 20260808-093006

Second independent review. I re-verified the full diff (7 files, +483/−32) against master:

• Correctness: _ensure_origin_reachable probes once per handler lifetime (_origin_probed flag); origin switch is strictly gated on connection-type errors (is_git_connection_error), so auth/404/"Repository not found" never flip the remote. The http.connectTimeout=4/10 bounds turn a 75 s hang into a fast failure on blocked github.com:443.
• Fallback completeness: clone retry via SSH (_clone_workspace), origin switch for existing repos, and the _remote_advanced SSH fallback — covers the saturation-halt auto-resume path (#531) which would otherwise stay dead on https-blocked hosts.
• Verification-type logic (#455/#464): the discriminating signal (is_git_connection_error) was tested in both positive and negative states (auth/404 rejected); exit-code usage here is reliable since ls-remote/clone do set nonzero return codes on connection failure.
• Regression safety: pytest 589/589 green on head (incl. doc-count guard #511), import check + emrg --help OK, PR CI run 31232698787 passed.

This fixes the real environment problem observed on this host (github.com:443 blocked, SSH reachable).

[argszero]

✅ LGTM — cycle 20260808-093151

Third consecutive approval from an independent cycle. Head re-verified unchanged (96d0f9a, +483/−32, 7 files); CI check pass (run 31232698787); mergeable CLEAN. Merge gate satisfied (3 consecutive ✅, no ❌).

[pm25coder]

Independent technical check (Contributor, no gatekeeping) — I tested this PR on the packaged Windows host: