Skip untracked symlinks-to-directories in the review diff

[adamw]

An untracked symlink pointing at a directory aborted the whole review loop.

git status --porcelain -uall reports such a symlink as a single ?? linkdir
entry — git does not recurse into it. git diff --no-index -- /dev/null linkdir
then follows the link, finds a directory on one side and a file on the other,
and tries to pair /dev/null with linkdir/null:

error: Could not access 'linkdir/null'

exit 1, message on stderr. OsGitTool.untrackedFileDiff classifies that
correctly — its exit 1 && empty stderr predicate means "the sides differ", and
this is exit 1 with stderr — so it calls fail, which throws
OrcaFlowException. One such symlink anywhere in the working tree took down
reviewDiff() and with it the review loop.

The fix

The predicate is untouched. It was tightened deliberately in #46, and it is
correct: before that, exit 1 was unconditionally read as "the sides differ",
which swallowed a real failure — from a subdirectory, git diff --no-index -- /dev/null sub/newfile.txt also exits 1 with an access error, and every new
file's contents were vanishing while reviewDiff() reported success. Loosening
it would restore that bug. The symlink case is the same signal from a different
cause, so the fix is to stop asking git to render the path at all.

untrackedFileDiff now short-circuits a symlink that resolves to a directory
and emits a line naming it instead. It is the single shared path — both
reviewDiff() and pendingChanges() reach it through withNewFileContents —
so both are fixed once.

What was measured, not assumed

Against git 2.53.0, for each kind of untracked symlink:

symlink to	exit	stderr	stdout
a directory	1	error: Could not access 'linkdir/null'	empty
a file	1	empty	new file mode 120000, link target as content
nothing (dangling)	1	empty	new file mode 120000, link target as content

Only the directory case is broken. git never follows a symlink to a file — it
renders the link itself as a mode-120000 blob holding the target path.

Only directory symlinks are held back, not all symlinks: a symlink to a file
or to nothing already renders correctly and is a real change the reviewer should
see, so dropping those would trade one silent omission for another.

Skipped symlinks are announced, not silently omitted, as a
# skipped <path>: symlink to a directory line. A reviewer who believes it saw
everything is worse than one told something was skipped — the same reason
CommitDiff marks a truncated diff. It also keeps the reviewer able to flag a
newly created symlink at all, which matters given this repo already treats
symlinks in the working tree as a surface worth refusing (OrcaDir,
ProgressScan).

untrackedPaths() is deliberately left alone, so pendingChanges().newFiles
still lists the symlink — verified that git add -A does commit it, as a
mode-120000 blob, which is exactly what that list promises.

Tests

Two in OsGitToolTest, each mutation-checked to fail alone.

The abort. A repo with an untracked symlink-to-directory alongside an
ordinary new file. Replacing the guard condition with false fails exactly this
test, with orca.OrcaFlowException: git diff --no-index -- /dev/null linkdir failed (exit 1): error: Could not access 'linkdir/null' — the reported error
verbatim.

How narrow the filter is — deliberately not a test of the fix, and not
redundant with the one above. It pins that a symlink to a file still renders
as its own mode-120000 diff. Widening the guard to os.isLink(path) alone fails
exactly this test and nothing else; without it, that widening would silently
swallow every file-symlink's diff — the same "reviewer told nothing was there"
failure this PR exists to prevent. Please don't delete it as a duplicate of the
directory test; it guards the decision, not the bug.

Sequencing vs #59

Branched off master, not off #59. #59 (review-change-set-since-stage-base)
adds a since parameter and touches reviewDiff, withNewFileContents and the
trait scaladoc in the same file, but does not touch untrackedFileDiff or
untrackedPaths — the two changes are independent. Whichever merges second
picks up a small conflict in the reviewDiff scaladoc block and in
withNewFileContents's signature; both resolve by keeping both edits. No
ordering is required either way.

Known adjacent defect, not fixed here

The identical abort fires for an untracked nested git repository: git status -uall does not recurse into one either, reporting ?? nested/ (with a
trailing slash), and git diff --no-index -- /dev/null nested/ fails the same
way with error: Could not access 'nested/null'. Verified on git 2.53.0. It is
a different cause with a different fix and a different message, so it is left
for its own change rather than widened into this one.