Add the server rollover, its systemd units, and an installer

Never modifies an existing note. It only creates today's file when that
file is absent, so the blast radius is one new file and re-running is a
no-op.

Two bugs that only a real run on the server could surface. tempfile
creates 0600 and os.replace preserves it, so notes would have landed
private in a tree where everything is 0644 and both sftpgo and syncthing
read; the previous note's mode is now carried over rather than hardcoded.
And --dry-run fell into a degenerate branch once today's file existed,
emitting a bare heading exactly when a preview is most wanted, so it now
always previews from the newest note that is not today.

The unit is sandboxed, and that was verified against the NFS mount rather
than assumed: writes to the notes directory succeed, and writes to its
parent are refused.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PU5ZFfQFtDTFqqhvMTWdGH

rollover/todo-rollover.service

@@ -0,0 +1,22 @@
+[Unit]
+Description=Roll today's todo note forward from the most recent one
+Documentation=https://github.com/connorjohnstone/todo
+After=network-online.target remote-fs.target
+Wants=remote-fs.target
+
+[Service]
+Type=oneshot
+User=connor
+Group=connor
+ExecStart=/home/connor/.local/lib/todo/rollover.py
+# The notes live on an NFS mount, so a stalled server must not wedge the timer.
+TimeoutStartSec=120
+PrivateTmp=true
+ProtectSystem=strict
+ProtectHome=read-only
+ReadWritePaths=/home/connor/docs/notes/todo
+NoNewPrivileges=true
+PrivateDevices=true
+ProtectKernelTunables=true
+ProtectControlGroups=true
+RestrictSUIDSGID=true