refactor: parameterize deploy/stop pipeline status to eliminate SQL literal duplication

[Copilot]

The deploy and stop workflow pipelines were ~95% identical, differing only in the hardcoded status string literal ('active' vs 'stopped') embedded directly in the SQL UPDATE query.

Changes

• admin/config.yaml — both pipelines (/deploy, /stop):
  • Prepend a set-target-status step (step.set) that declares the semantic difference at the top of each pipeline
  • Change update-status SQL from status = 'hardcoded' to status = ? placeholder
  • Add set-target-status.target_status as the first param in update-status

The update-status step and SQL query are now structurally identical between the two routes. The sole difference is isolated to set-target-status:

# deploy pipeline
- name: set-target-status
  type: step.set
  config:
    values:
      target_status: "active"

# stop pipeline
- name: set-target-status
  type: step.set
  config:
    values:
      target_status: "stopped"

# shared update-status step (identical in both pipelines)
- name: update-status
  type: step.db_exec
  config:
    database: admin-db
    query: "UPDATE workflows SET status = ?, updated_at = ? WHERE id = ?"
    params:
      - "{{index .steps \"set-target-status\" \"target_status\"}}"
      - "{{index .steps \"set-now\" \"now\"}}"
      - "{{index .steps \"parse-request\" \"path_params\" \"id\"}}"

db_exec rejects template expressions in SQL strings (SQL injection guard), so parameterization via ? + params array is the correct approach here.

---

🔒 GitHub Advanced Security automatically protects Copilot coding agent pull requests. You can protect all pull requests by enabling Advanced Security for your repositories. Learn more about Advanced Security.