Disabled deployments remain disabled when replicas are updated to >= 1

Describe the bug
When re-enabling disabled deployments (deployments with 0 replicas) by setting replicas back to >= 1 they remain disabled.

To Reproduce
Create a deployment with zero replicas ( or create one with x replicas and then update it to 0).

curl -X POST https://api.cloud.cbh.kth.se/deploy/v2/deployments \
-d'{
  "name": "randombugtestname",
  "cpuCores": 0.1,
  "ram": 0.1,
  "replicas": 0,
  "envs": null,
  "volumes": null,
  "initCommands": null,
  "args": null,
  "visibility": "private",
  "neverStale": false,
  "private": false,
  "image": "phillezi/litelogger:latest",
  "healthCheckPath": null,
  "zone": null
}' \
-H "Content-Type: application/json" \
-H "Authorization: Bearer <keycloak-jwt>" # or use X-Api header with a api token

(can be done on the swagger ui or through cloud.cbh.kth.se instead of curl too.)

Then re-enable it:

curl -X POST https://api.cloud.cbh.kth.se/deploy/v2/deployments/<deployment-id> \
-d'{
  "replicas": 1
}' \
-H "Content-Type: application/json" \
-H "Authorization: Bearer <keycloak-jwt>" # or use X-Api header with a api token

(can be done on the swagger ui or through cloud.cbh.kth.se instead of curl too.)

It remains disabled, despite having 1 replica. It gets updated if i update another spec like the cores or ram.

Expected behavior
The deployment should be re-enabled when replicas are updated to > 0.

Workaround fix
If you update cores or ram after changing the replicas back to > 0 it should re-enable it.

Start at the deployment update endpoint, POST /deploy/v2/deployments/, and trace how a replicas change is handled when the current value is zero. Reproduce the issue through the API or Swagger UI; done means changing replicas from 0 to 1 re-enables the deployment without changing cores or RAM.