Don't recommend nix-env in installation instructions - #14021

…er probe harness

Two corrections to the probe work committed in bb33b9e.

1. The line-ending claim was wrong. One probe body round-tripped as LF, and
   that was generalised into "no line-ending rewrite". Both forms occur in
   real issue bodies -- cli/cli#14021 comes back CRLF, cli/cli#14031 LF, same
   repo, both with HTML comments intact; the submission path decides. The
   contract now requires every backend to normalise to \n on read before
   parsing or comparing, and to write \n. Without it a human's web-UI edit can
   flip a region to CRLF and the next chart reports every line as changed,
   breaking the byte-identical no-op guarantee on text nobody touched. The key
   marker is single-line and safe either way; region content is not.

2. Replaced the ad-hoc GitHub-only script with the real harness,
   probe_marker_survival.py: both trackers, dry-run by DEFAULT, --yes plus an
   explicit target required to write, --phase setup/verify/cleanup/auto with
   state in a file so the human web-UI step works non-interactively, cleanup in
   try/finally, write throttling. Exercised end to end against the throwaway
   private repo: 34 API calls, seven steps PASS, cleanup fired.

   It is better than what it replaces in two ways that matter. It normalises
   CRLF before byte-comparing -- the exact bug in correction 1. And it refuses
   to report markerSurvives from steps 1 and 4 alone, emitting null plus "do
   not write join code on steps 1/4 alone" until step 3 is really run; the
   retired script would have implied a pass. The retired script also claimed
   issues cannot be deleted -- true of REST, false of GraphQL deleteIssue,
   which the harness uses for --purge.

   Its ADO adapter is written from Microsoft Learn reference docs and has
   NEVER been executed. Treat it as unexercised code, not a verified path.

Also recorded from the grounding pass: dependencies cap at 50 per relationship
type (separate from the 100 sub-issue cap); a sub-issue need only share the
parent's OWNER, so it may live in another repo and the join must key on parent
identity rather than "same repo"; and DELETE takes the singular /sub_issue path
with the id in the request body.

Both verdicts are kept: the human-step-3 run is the authoritative evidence, the
harness run is the reproducible baseline that honestly reports itself undecided.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>