Secrets sweep: move hardcoded credentials out of tracked files into env files

Removed live secret literals from git-tracked code (all were on GitHub):

- deploy/reactor.py: Claude/Groq API keys, DB pass, Gmail/iCloud app passwords now from os.environ (loaded via systemd EnvironmentFile=/etc/jarvis-arc/reactor.env, root:www-data 0640)

- public_html/login.php: used a private hardcoded PDO connection; now uses config.php DB_* constants

- deploy/jarvis-backup.sh (runs via cron), jarvis-deploy.sh, jarvis-watchdog.sh: DB pass now sourced from /etc/jarvis/db.env (root:root 0600)

- removed dead agent/jarvis-arc-reactor.py (unreferenced old duplicate leaking an old Groq key + stale Ollama IP)

- added deploy/reactor.env.example and deploy/db.env.example templates

Verified live: reactor restarted with all 21 handlers + DB poller (job round-trip OK), login works, mysqldump auth via env OK.

NOTE: these keys remain in GitHub history and should be rotated (Claude/Groq/Gmail/iCloud/DB). Separate decision needed on INFRASTRUCTURE-REFERENCE.md (full cred doc still tracked) + history purge.

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

deploy/jarvis-backup.sh

@@ -1,4 +1,5 @@
 #!/bin/bash
+[ -r /etc/jarvis/db.env ] && . /etc/jarvis/db.env
 # JARVIS backup — DB dump + all files needed to actually restore JARVIS, as tar.gz
 # Fixed 2026-07-07: this only ever backed up the MySQL database. If this VM were
 # lost, the DB alone is useless without the application code, the reactor daemon,
@@ -9,7 +10,7 @@ LOG="$BACKUP_DIR/backup.log"
 LOCK="$BACKUP_DIR/backup.lock"
 DB_NAME="jarvis_db"
 DB_USER="jarvis_user"
-DB_PASS="J4rv1s_Pr0t0c0l_2026!"
+DB_PASS="${JARVIS_DB_PASS:?DB pass unset - see /etc/jarvis/db.env}"
 TIMESTAMP=$(date +"%Y%m%d_%H%M%S")
 OUTFILE="$BACKUP_DIR/jarvis_backup_${TIMESTAMP}.tar.gz"
 TMPDIR=$(mktemp -d)