a symlink in the sorted directory no longer redirects a step

Placeholders were already stopped from sending a file out of the
directory a rule named. A symlink is a name too, and the directory
krino sorts is by the threat model's own premise a place the internet
writes into: a link named after a rule's destination sent moves and
copies anywhere, and under (on-conflict overwrite) trashed a file
OUTSIDE the sorted directory - while the plan showed the in-tree text
and the run reported success.

A step whose destination passes through a symlink at or below the
directory being sorted now fails. A destination the configuration names
outside it - ~/docs on another disk - is the user's own arrangement and
is followed as before; both cases have a test.

End to end, the review's scenario (Out -> ~/secret, overwrite):

  before: 1 applied, the user's file replaced and trashed
  after:  0 applied 1 failed, the file untouched, nothing trashed

Two bookkeeping bugs in MkdirAllTracked went with it: a dangling
symlink read as a missing directory and was then recorded as one krino
had created - undo would have unlinked a link krino never made - and a
directory created by someone else between the check and the mkdir was
recorded the same way.

1 files changed, 9 insertions, 2 deletions

diff --git a/internal/plan/step.go b/internal/plan/step.go
index c613ce5..0b554d3 100644
--- a/internal/plan/step.go
+++ b/internal/plan/step.go
@@ -52,8 +52,15 @@ type Step struct {
 
 // Chain is one file's steps, in order.
 type Chain struct {
-	File     scan.File
-	Steps    []Step
+	File  scan.File
+	Steps []Step
+
+	// Root is the directory being sorted. Apply uses it to tell a
+	// destination inside that directory - where anything at all may have
+	// been written, by a download or an unpacked archive - from one the
+	// configuration named itself, which is the user's own arrangement.
+	Root string
+
 	Warnings []string
 }