nova-check links opens the tree a symlinked --dir names

nova-check links opens the tree a symlinked --dir names. Until now a --dir that was a symbolic link to a tree passed its directory check and then walked nothing, because the walk does not follow a link at its root, and the tool printed LINKS OK files=0 links=0 and exited 0 over a tree it never opened. A checker that reports a clean pass over nothing is worse than no checker, and a seed's copies are often checked through a link. The nocode checker had the same defect and was repaired earlier with a resolved root; links now does the same, line for line: the root is resolved with filepath.EvalSymlinks, checked, refused with exit 2 and the caller's spelling when it is not a directory, and only then walked. Reported paths are unchanged and still relative to the tree, and nothing below the root is followed that was not followed before.

What ships is the repair in internal/check/links.go; a test, TestLinksDirIsASymlinkToTheTree, that fails on the previous binary and passes on this one; a CI step that runs the tool through a symlinked --dir and asserts the exact failure line, shown to fail against the pre-repair binary; and the refusal paragraph of SPEC.md made true of the code.

One cold reader on the strongest available model, told first what would change its ruling, reproduced the defect and the repair, reverted the fix to watch the test go red, walked a tree holding in-tree links that point outside it on the old and new binaries by real path and by link, and found nothing blocking. The three things it named beside the ruling are filed as #32, #33 and #34: an unresolvable --dir is refused by the name of its target rather than the path typed, in links and nocode alike; the SPEC sentence is still a little narrower than the code for a directory inside the tree that cannot be listed; and this repository cannot run links over itself because a test fixture's links point into the seed on purpose.

Take what fits; nothing here can weaken a floor.