fix: point dump_db.sh at its /opt/backup-agent deploy path, remove healthcheck

dump_db.sh no longer lives under $TARGET, so its own default dump
directory (relative to wherever the script is) would land outside the
backed-up tree. Pin DUMP_SCRIPT to /opt/backup-agent/dump_db.sh and
export DUMP_DIR explicitly so dumps still land in $TARGET/mariadb/dump
regardless of where the script itself is deployed.

Also drop the healthcheck integration (HEALTHCHECK_URL, send_healthcheck,
curl requirement) from borg-backup.sh per request - no monitoring hook
wanted for now.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

CLAUDE.md

@@ -7,7 +7,7 @@ This file provides guidance to Claude Code (claude.ai/code) when working with co
 Backup + disaster-recovery tooling for a Linux server: Borg (encrypted, offsite-synced via rclone) backing up `/home/srv/files/content`, including MariaDB running in Docker. Plain bash, no build system, no CI, no test suite. `RUNBOOK.md` is the operational doc (setup, deploy, cron, day-2 ops, recovery).
 
 - `borg-backup.sh` — daily backup orchestrator (cron). Never stops MariaDB: `dump_db.sh`'s `--single-transaction` dump is consistent on its own, and the raw data directory is excluded from the archive via a `.nobackup` marker file.
-- `dump_db.sh` — per-database `mysqldump`/`mariadb-dump` with atomic staging/swap. Deployed to `/home/srv/files/content/mariadb/dump_db.sh` (borg-backup.sh invokes it at that exact path).
+- `dump_db.sh` — per-database `mysqldump`/`mariadb-dump` with atomic staging/swap. Deployed to `/opt/backup-agent/dump_db.sh` (borg-backup.sh invokes it at that exact path). It defaults to writing dumps next to itself, so borg-backup.sh always overrides `DUMP_DIR` to keep dumps inside `$TARGET` where borg can see them.
 - `restore.sh` — recovery CLI: `full` (disaster recovery), `db <name>`, `file <path>`, `--list-archives`, all supporting `--dry-run`.
 
 ## Global conventions (don't re-derive these)

RUNBOOK.md

@@ -50,14 +50,13 @@ Run once, by hand, on the server:
 
 ## 2. Deploying the Scripts
 
-Copy `borg-backup.sh`, `dump_db.sh`, and `restore.sh` to the server (e.g.
+Copy `borg-backup.sh`, `dump_db.sh`, and `restore.sh` to `/opt/backup-agent/`
-`/opt/backup-agent/`), and `dump_db.sh` additionally to
+(this exact path is what `borg-backup.sh` invokes for `dump_db.sh`). Make
-`/home/srv/files/content/mariadb/dump_db.sh` (this exact path is what
+all three executable:
-`borg-backup.sh` invokes). Make all three executable:
 
 ```bash
 chmod +x /opt/backup-agent/borg-backup.sh /opt/backup-agent/restore.sh
-chmod +x /home/srv/files/content/mariadb/dump_db.sh
+chmod +x /opt/backup-agent/dump_db.sh
 ```
 
 ## 3. Scheduling

borg-backup.sh

@@ -25,6 +25,12 @@ NAME="borg-2025"
 REPO="/home/srv/files/backups/$NAME"
 TARGET="/home/srv/files/content"
 
+# dump_db.sh lives with the rest of this toolkit, not inside $TARGET - its
+# own default dump dir is relative to wherever IT lives, so DUMP_DIR must be
+# passed explicitly (below) to keep dumps inside $TARGET where borg can see them.
+DUMP_SCRIPT="/opt/backup-agent/dump_db.sh"
+export DUMP_DIR="${TARGET}/mariadb/dump"
+
 REPO_MOUNT=""
 
 LOGDIR="/var/log/borg"
@@ -217,8 +223,6 @@ preflight
 
 # --- 1. Logical dumps (container stays up the whole time) ---------------
 step "Step 1: MariaDB dumps"
-DUMP_SCRIPT="${TARGET}/mariadb/dump_db.sh"
-DUMP_DIR="${TARGET}/mariadb/dump"
 
 if [[ ! -x "$DUMP_SCRIPT" ]]; then
     log "ERROR: dump script missing or not executable: $DUMP_SCRIPT"