Hold back blocking packages instead of failing the whole upgrade

A repo package that replaces something an installed AUR package still depends
on aborted the entire transaction, and would have done so on every subsequent
run - one stale AUR package was enough to cut a machine off from all updates
indefinitely. Observed in the wild: percona-server-clients replaces
libperconaserverclient without providing it, while heidisql-qt6-bin hard-depends
on it, blocking 213 unrelated package updates.

pacman names the offending package in its dependency errors, so it is now
extracted and passed to --ignore for one retry: the other 213 packages go
through and the blocker is reported. The hold is per-run, never written to
IgnorePkg, so it disappears by itself once upstream catches up.

The single retry is also now a bounded recovery loop, because fixing one
problem regularly uncovers the next - a conflict resolved with --ask=20 can
surface a dependency error behind it. Each remedy is applied at most once.

The held-back set is shown in the menu and notified only when it changes, so a
blocker waiting on an upstream fix does not produce the same message daily.

src/cachy-auto-update-run

@@ -202,6 +202,22 @@ else
 	fi
 fi
 
+# Packages skipped so the rest of the upgrade could proceed. The notification
+# only fires when the set changes: a blocker waiting on an upstream fix would
+# otherwise produce the same message every single day.
+prev_held="$(cau_state_read held_back '')"
+if [[ -n $CAU_PACMAN_HELD ]]; then
+	cau_state_write held_back "$CAU_PACMAN_HELD"
+	cau_warn "Held back: $CAU_PACMAN_HELD"
+	if [[ $CAU_PACMAN_HELD != "$prev_held" && $CFG_NOTIFY_ERROR == yes ]]; then
+		cau_notify normal "Some packages were held back" \
+			"%s could not be updated and was skipped. Everything else is up to date." \
+			"$CAU_PACMAN_HELD"
+	fi
+else
+	cau_state_clear held_back
+fi
+
 if cau_pacman_reboot_needed; then
 	cau_state_write reboot_needed 1
 	cau_info "A kernel update needs a restart"