95 corpus references still name d-morrison/gha and d-morrison/wai after their transfer to Morrison-Lab

[d-morrison]

Noticed while driving #1378, whose own diff sits in a paragraph that writes d-morrison/gha. Deferred out of that PR deliberately (its "Claims not made" section says so) because the naming predates the diff and spans the corpus; filing so the deferral is tracked rather than dropped.

Sibling of #808, which covers d-morrison/ai-config in README.md and already names "whether any other tracked file names the old owner" as an in-scope sweep item. This issue is the same class for the other two transferred repos, which #808's title and body do not reach.

Measured

Whitespace- and markup-normalizing scan over tracked .md/.yml/.yaml/.json/.py/.sh (a literal grep undercounts in this corpus, since a path can straddle a semantic line break):

reference	occurrences	files	status
d-morrison/gha	83	26	stale --- redirect
d-morrison/ai-config	34	15	stale --- redirect, tracked by #808
d-morrison/wai	12	7	stale --- redirect
d-morrison/altdoc	55	20	correct as written
d-morrison/rme	25	13	correct as written
d-morrison/macros	19	10	correct as written

So the sweepable set is 95 occurrences (gha + wai), not the 228 a naive grep -c 'd-morrison/' reports.

The half that matters most: which ones must NOT be swept

altdoc, rme, and macros are not under Morrison-Lab at all --- only the d-morrison path resolves for each. A blanket owner rewrite would turn 99 correct references into broken ones, which is the opposite of the intended fix. Derived rather than assumed:

$ for r in gha ai-config rme altdoc wai macros; do
    a=$(git ls-remote --heads "https://github.com/d-morrison/$r"   HEAD >/dev/null 2>&1 && echo yes || echo no)
    b=$(git ls-remote --heads "https://github.com/Morrison-Lab/$r" HEAD >/dev/null 2>&1 && echo yes || echo no)
    printf '%-12s d-morrison=%-3s Morrison-Lab=%s\n' "$r" "$a" "$b"
  done
gha          d-morrison=yes Morrison-Lab=yes
ai-config    d-morrison=yes Morrison-Lab=yes
rme          d-morrison=yes Morrison-Lab=no
altdoc       d-morrison=yes Morrison-Lab=no
wai          d-morrison=yes Morrison-Lab=yes
macros       d-morrison=yes Morrison-Lab=no

"Both resolve" is consistent with a redirect or with two distinct repos, so that read alone does not establish a transfer. Comparing HEAD settles it --- an identical SHA under both owners is one repo behind a redirect:

$ git ls-remote https://github.com/d-morrison/gha   HEAD   # c05ca95cdb33
$ git ls-remote https://github.com/Morrison-Lab/gha HEAD   # c05ca95cdb33

Same for ai-config (0fc5fec30a3e both) and wai (6aab2621bddb both).

Nothing is broken today

Every one of the 95 resolves, because GitHub keeps a redirect after a transfer --- the same finding #808 records. This is staleness, not breakage. What the redirect does not survive is someone creating a new repo at the old path, and a corpus split roughly evenly between two spellings of the same repo is a maintainability cost regardless.

Proposed scope

1. Rewrite d-morrison/gha -> Morrison-Lab/gha and d-morrison/wai -> Morrison-Lab/wai across tracked files.
2. Leave altdoc, rme, and macros alone, and say so in the PR body so a later reader does not "finish the job".
3. Re-run the resolve check in the same pass rather than trusting this table --- a repo can be transferred between now and then, which would move a row from the second group to the first.
4. Coordinate with README still points at d-morrison/ai-config after the transfer to Morrison-Lab #808 so the ai-config third of the sweep is not done twice or missed by both.

Bare gha#NNN issue citations (dozens across shared/, memories/, and CLAUDE.md) carry no owner and need no change.