consolidate-memory: splitting or deleting a file leaves [[wikilinks]] dangling, and no scan covers them

[jsirish]

consolidate-memory scans for four problem types (SKILL.md:13,15,31): duplicates, stale entries,
unindexed orphans, and index orphans. None of them looks at [[wikilinks]] between memory files.

On a recent run the skill did exactly what it was asked: split an oversized memory file into two and
deleted the original. Two sibling files still carried [[original-name]] links, which were now
dangling. Nothing flagged it — the index was clean, so all four scans passed. It was found only by
grepping for the deleted name afterwards, by hand.

Splitting and deleting are the skill's own primary operations, so it is uniquely positioned to break
these links and uniquely unable to notice.

Ask:

1. Add a fifth scan: for every [[target]] across the memory directory, assert a file with that
   name: exists. Run it as a post-operation check after any split, rename or delete, not only as a
   standalone scan.
2. On a split, rewrite inbound links to point at whichever half now carries the content, or at
   minimum list them for the operator to resolve.

Secondary, same run: an edit target that is a symlink is refused outright by the harness's Edit
tool ("Refusing to write ... it is a symbolic link"). Since promotion targets are routinely symlinked
config files, the skill should resolve the link and edit the real path.

[agentdynamic]

The autobuild loop is starting work on this (phase 2 execution). Branch: claude/consolidate-memory-dangling-wikilinks.

[agentdynamic]

Work is pushed and open as #94 (branch claude/consolidate-memory-dangling-wikilinks, 3 commits, all five CI checks passing, local CI all PASS).

The fifth scan and the post-operation re-scan this issue asked for are both implemented, along with the symlinked-edit-target rule from the secondary ask. Two review rounds produced real defects in the new instructions - a Phase 4 remediation that covered only splits when merges are what actually delete files, a Phase 3 example that modelled writing a filename inside a link, target extraction that mishandled #anchors, table-escaped pipes and quoted YAML scalars, and a filename-match rule that contradicted the missing-name: case - and all of those were fixed and pushed after a fresh local CI pass.

Stopping reason: review-unresolvable. A third review round opened further findings and the review gate then hit its cumulative non-clean-rounds cap (3/3) and declared itself terminal, which forbids another round or another push in this session. None of round 3's findings is fixed; the full text of that round is in the PR's latest comment, and its advisory items are filed as #95. The PR is left open exactly as pushed, for a human or a later revise round.