feat(install): diagnose a blocked package index instead of retrying blindly

[Jason Robert (jrob5756)]

Problem

Installs fail on networks that block direct access to the public Python
package index — increasingly common on managed corporate devices, where a
policy requires all packages to come from an internal mirror.

uv tool install fails with a fetch/403/DNS-shaped error, and uv has
already exhausted its own retries by that point. So the install scripts
spent their full 2s/5s/10s backoff on a failure that cannot heal, and
install.ps1 then printed file-lock advice — including a suggestion to add
a Windows Defender exclusion, which is useless and actively misleading
for a network-policy block.

The user-visible experience was three silent retries followed by wrong
advice. Nothing named the actual cause, and nothing named the setting that
fixes it.

What changed

Classification. Both scripts now sort a failed install into one of four
kinds and respond to each differently:

Failure	Retries	Message
Definitive index block (uv gave up; 401/403/407/DNS/TLS)	stops immediately	how to point uv at your index
Unreachable github.com	full schedule	names github.com, says the index is not the problem
Connection blip (connection reset, timeout)	full schedule	index guidance only if the run ends on it
Anything else (build error, hash mismatch, lock)	full schedule	existing advice, unchanged

The scripts also echo the active index at install time — with credentials in
the URL redacted — so "did my override apply?" is answerable from the
install log alone.

README.md — new Installing behind a proxy or private package index
section: uv (env var, uv.toml, named-index credentials, TLS inspection,
proxies) and pip/pipx separately, including the trap that uv does not read
pip's configuration.

No vendor endpoint is hardcoded

Conductor is public OSS installed on many different networks. A baked-in
mirror would silently redirect every other user's dependency resolution, so
the index stays user-supplied configuration and the docs use a
<your-index-host> placeholder.

A static test enforces this by shape rather than by denylisting known
vendors — it matches any https://…/simple/ URL and requires it to be
either pypi.org or the placeholder. That catches a mirror the test's
author never heard of, and avoids naming anyone's internal infrastructure
inside a public repo.

Second commit: review fixes

A multi-agent review found four issues that were reproduced against real uv
0.11.30 and a faithful simulation of each script's retry loop before being
fixed:

• A blocked github.com was reported as a blocked package index. uv
  words a failed git fetch with the same "failed to fetch" phrase it uses
  for the index, and the installer fetches Conductor itself from
  git+https://github.com/... — so github.com is on the primary path for
  every install. The user would set a perfectly correct UV_DEFAULT_INDEX,
  fail identically, and conclude the URL was wrong.
• On Windows the index classifier was unreachable on a fresh install
  whose output also contained lock-shaped text. The lock fallback guarded on
  the result of the rename, and Move-ConductorToolDirAside returns
  $null when there is no existing tool dir — so the guard never flipped,
  the branch continued on all four attempts, and the run ended on the
  Defender advice this PR exists to avoid.
• Classification read the accumulated log, so one transient blip
  anywhere in a run relabeled whatever the run finally failed on: a missing
  portaudio.h was reported as a blocked index.
• The needles were too broad. Matching pypi.org alone reported a hash
  mismatch as an unreachable index — the worst available answer for a
  supply-chain signal. Bare host needles are gone; every needle now names a
  failure.

Also in that commit: credentials redacted in the echo; guidance adapts when
an override is already set rather than advising what the user already did;
the named-index form throughout so the documented UV_INDEX_<NAME>_*
credentials are actually usable; TLS-inspection and proxy remedies named; a
missing log no longer kills install.sh with a bare sed error; the
renamed-aside notice prints before any early exit; 401 matched; grep
pinned to LC_ALL=C; PowerShell lowercases invariantly; and the CHANGELOG
corrected (the Defender advice was never rescoped — Write-Err just exits
before it — and install.sh never had Defender advice to rescope).

Verification

Behavior was exercised end-to-end against a fake uv, including the Windows
path under PowerShell 7.4. install.sh and install.ps1 agree on all seven
scenarios:

Scenario	attempts	classified as
Blocked index	1	index
Block first appears on attempt 2	2	index
Lock + network, fresh install	2	index
Transient blip + build failure	4	generic
Unreachable git host	4	github.com
Hash mismatch	4	generic
Ordinary build failure	4	generic

Underlying uv behavior was confirmed against real uv 0.11.30 rather than
assumed: UV_DEFAULT_INDEX redirects resolution; a git+https://… install
routes build deps (packaging) through it too; the deprecated
UV_INDEX_URL still works; and an unreachable git host really does emit
failed to fetch, which is what made the misdiagnosis above possible.

Tests

• _uv_shim.py gained seven modes and a POSIX shim (it was Windows-only).
• Six behavioral tests: blocked index, ordinary failure (the negative
  direction), transient blip, late block, both classifiers matching, and a
  git-host failure.
• Four static checks in the default make test suite.
• Every fix was negative-controlled — reverting it makes its test fail.
  Two tests were themselves found to be vacuous during review and fixed: the
  guidance assertion was satisfied by the scripts' header comments with all
  guidance functions deleted, and the classifier assertion passed for a
  function that was defined but never called.

Full suite: 7064 passed; install-scripts 10 passed / 4 skipped; ruff and
ty clean; install.ps1 still ASCII / no BOM / LF.

Notes for reviewers

• This makes the failure legible; it does not configure anything. Users
  on a restricted network still supply their own index — by design.
• Publishing to PyPI would be complementary, not a replacement: it would
  remove the from-source build (and its build-backend fetches), but a
  blocked network still needs the mirror.

Draft for review of approach before polish.