prepare-data-dir leaves files with a second name to their owner (closes #143)

A hard link in /data shares its owner with a file that can be anywhere
on the same filesystem, so chowning it gave that file to the netwatch
user. A file with more than one name now keeps its owner and its path
is logged.

Owners are now set on the opened directory, file or link after
checking it, as chmodDir sets modes, so a hard link swapped in
afterwards is caught. Every other file is opened without following it;
a symbolic link is given to the netwatch user itself, and devices,
named pipes and sockets keep their owner. This is built only for
Linux: prepare-data-dir runs only in the Linux image, and macOS has
neither O_PATH nor AT_EMPTY_PATH; elsewhere it returns an error. A
failed owner change names the file.

Model: opus-5-5

TODO.md

@@ -21,6 +21,21 @@ Run `make frontend-viewport-test` in CI as its own step; it is not part of
 
 # Completed Steps
 
+- 2026-10-18: `netwatch-server prepare-data-dir` no longer changes the owner of
+  a file outside `/data` through a hard link in the volume
+  ([#143](https://git.eeqj.de/sneak/netwatch/issues/143)). A file with a second
+  name (hard link) keeps its owner, and the start logs its path. Owners are now
+  set on the opened directory, file or link, never by name, so a hard link
+  swapped in after the check is caught too; a symbolic link is opened without
+  following it and given to the netwatch user itself, so the server can still
+  follow one in a sticky directory that anyone can write to. Devices, named
+  pipes and sockets keep their owner. Setting the owner on an open file that is
+  not a directory is built only for Linux: `prepare-data-dir` runs only in the
+  Linux image, and macOS, where the backend is also built for development, has
+  neither `O_PATH` nor `AT_EMPTY_PATH`. On any other system the package still
+  builds, and `prepare-data-dir` fails at the first file that is not a
+  directory. The test that runs as root hard-links a file, a symbolic link and a
+  named pipe from outside the volume into it and finds their owners unchanged
 - 2026-10-18: from a trusted proxy, the backend takes the client address from
   the right-most `X-Forwarded-For` entry that is not in `TRUSTED_PROXIES`
   ([#144](https://git.eeqj.de/sneak/netwatch/issues/144)). It took the left-most