Health/deploy crash with unbound variable on stacks missing env vars

[gfargo]

Summary

Several strut commands crash with "unbound variable" errors when run against stacks that don't have the expected env vars defined. This affects health checks, deploy migrations, and stacks without a fully populated .prod.env.

Examples

1. backup stack health check

/dev/fd/63: line 6: PIOPS_VPS_HOST: unbound variable
✗  [backup/prod/health] Remote command failed

The backup stack has no compose file and no .prod.env with VPS_HOST defined. Health should gracefully report "no remote target configured" instead of crashing.

2. Deploy runs migrations on non-DB stacks

During strut_deploy on octoprint-ender3:

[strut] [2/6] Running Postgres migrations...
/home/gfargo/.strut/lib/cmd_db.sh: line 162: POSTGRES_USER: unbound variable
⚠  [octoprint-ender3/prod/deploy] Postgres migration failed or no migrations to apply

[strut] [3/6] Running Neo4j migrations...
/home/gfargo/.strut/lib/cmd_db.sh: line 143: NEO4J_URI: unbound variable
⚠  [octoprint-ender3/prod/deploy] Neo4j migration failed or no migrations to apply

The deploy pipeline runs Postgres and Neo4j migration steps unconditionally. Stacks that don't use databases get "unbound variable" errors that are treated as warnings rather than being skipped.

Expected Behavior

1. Scripts should check if required vars are defined before using them (${VAR:-} or explicit guards)
2. Migration steps should be skipped entirely if services.conf has no DB_* flags (the health check already does this correctly — "Databases": "skip", "No DB_* flags in services.conf")
3. Health on stacks without a remote target should return a clean "not configured" status

Root Cause

The shell scripts use set -u (or equivalent) which causes unbound variable references to be fatal errors. The scripts need guard clauses or default values for optional env vars.

Environment

• strut version: 0.45.4, MCP server via strut mcp serve
• Affected stacks: backup (health), octoprint-ender3 (deploy migrations)

[gfargo]

Resolved by #519, which guards optional migration environment variables and skips database migrations cleanly for non-database stacks. Closing as fixed.