Backup writes silently retarget to the local disk if the S3 mount drops

`MONTHLY_BACKUP_DIR=/home/root1/s3bucket/chakra-backups/current_month`. If the S3 FUSE mount drops — and an unattended FUSE mount will — that path is just a plain local directory, so `mv` succeeds and 35-50 GB/day silently starts filling root1's root filesystem.

From a healthy disk that is days, not weeks. When it fills: Postgres refuses writes, gunicorn's unrotated logs fail, and lsyncd stalls mid-sync leaving root2 with partially-synced pages.

**Fix:** `mountpoint -q /home/root1/s3bucket || exit 1` at the top of `script.sh` — refuse to run rather than silently writing locally.

---

**Evidence**

```
chakrabackup-script/configs/zip_config.env; chakrabackup-script/backup_script/script.sh
```

- Verified against: `origin/master 44ca47e (2026-07-25)`
- Verdict: **CONFIRMED**

Read chakrabackup-script/backup_script/script.sh and the path configured in chakrabackup-script/configs/zip_config.env. Start by checking how the script handles the backup directory before its file operations. Done means the script refuses to run when the S3 FUSE mount is absent, while continuing normally when the mount is present.

Written by the indexing model from the issue text.