fix(crontab): clear user crontab as root so stale-owned spool files heal

On installs migrated from EasyDocker the spool file
/var/spool/cron/crontabs/<user> can be left owned by a defunct UID. The
sticky bit on the spool directory then blocks the current install user from
replacing it, so every `crontab -` write failed with
"rename: Operation not permitted" while the scripts still printed success.

crontabClear now removes the crontab as root (`crontab -u <user> -r`), which
bypasses the sticky bit and clears the stale file; the setup steps recreate
it owned by the install user, so the next crontab refresh self-heals.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Signed-off-by: librelad <librelad@digitalangels.vip>

scripts/crontab/crontab_clear.sh

@@ -1,8 +1,13 @@
 #!/bin/bash
 
 # Function to remove all crontab data
-crontabClear() 
+crontabClear()
 {
-    echo "" | sudo -u $sudo_user_name crontab -
+    # Remove the install user's crontab as root so a stale spool file owned by
+    # a defunct UID is cleared too — e.g. after the EasyDocker -> LibrePortal
+    # user rename. The sticky bit on /var/spool/cron/crontabs otherwise stops
+    # the user replacing a file it doesn't own ("rename: Operation not
+    # permitted"); setup recreates the crontab as the user next.
+    sudo crontab -u "$sudo_user_name" -r 2>/dev/null
     isSuccessful "All crontab data has been deleted."
 }