Renames the backup script to match the instance, not the software

backup-slpmodularcms-db.sh named the CMS; this backs up slpsoftware
specifically, same as every other instance-scoped path already does.
Hardcoded in deploy-scp.yaml itself, so this is the actual pipeline
code, not just docs describing it.

aidlc-docs/features/gitea-deployment-workflow/construction/u6-deploy-workflow/code/generation-summary.md

@@ -57,7 +57,7 @@ the documented boundary between Construction and Operations for this specific un
 
 ## Deferred to Operations (not built here, by design)
 
-- `~/scripts/backup-slpmodularcms-db.sh` on the host (referenced, not created — a host-side script
+- `~/scripts/backup-slpsoftware-db.sh` on the host (referenced, not created — a host-side script
   is out of this repository's scope)
 - `loginctl enable-linger` for the deploy user (**INFRA-U6-01**, carried from Infrastructure Design)
 - Actual values for `DEPLOY_PATH_*`, `SERVICE_NAME_*`, `HEALTH_CHECK_URL_*` Gitea variables and the

aidlc-docs/features/gitea-deployment-workflow/construction/u6-deploy-workflow/infrastructure-design/infrastructure-design.md

@@ -99,7 +99,7 @@ Per-environment sequence (test runs steps 1, 3–7; production additionally runs
 
 1. Download the build artifact (`actions/download-artifact`, unchanged from the reference project)
 2. **Production only** (Q8 = A): trigger a database backup over the existing SSH connection —
-   `ssh {user}@{host} 'bash ~/scripts/backup-slpmodularcms-db.sh'`. The backup script itself lives
+   `ssh {user}@{host} 'bash ~/scripts/backup-slpsoftware-db.sh'`. The backup script itself lives
    on the Pi and is created once during host setup (Operations, FR-23); the workflow never
    transmits or references database credentials, keeping D-16's "runtime secrets live in host
    environment variables, the workflow does not manage them" intact. This satisfies FR-20's