Reconcile the database override flag set/unset logic in the Lagoon deploy script

[AlexSkrypnyk]

Summary

The database override flag (VORTEX_PROVISION_OVERRIDE_DB) is set and unset in a way that interleaves two separate concerns and is duplicated across the pull-request and branch redeployment paths in .vortex/tooling/src/vortex-deploy-lagoon. The logic should be reconciled and consolidated.

Current behaviour

In the redeployment path (both the PR and the branch branch), the script:

1. Always sets VORTEX_PROVISION_OVERRIDE_DB to 0 as a workaround for uselagoon/lagoon#1922 (marked @todo to remove once that bug is fixed).
2. When the deploy action is deploy_override_db, it then sets the flag to 1 (to force a database import), triggers the deployment, waits, and sets the flag back to 0.

So in the override case the flag is written three times in a single run (0 -> 1 -> 0), and the whole block is duplicated verbatim in the PR and branch redeployment paths.

Problems

• Two distinct concerns are interleaved: the unconditional #1922 bug workaround (reset to 0) and the deliberate per-deploy override toggle (1 then reset to 0).
• The set/unset sequence is redundant - an initial reset to 0 is immediately followed, in the override case, by 1 and then 0 again.
• The block is duplicated across the PR and branch redeployment paths, so the two copies can drift out of sync.

Proposed work

• Consolidate the flag handling into a single place shared by the PR and branch paths.
• Clearly separate the #1922 workaround from the deliberate override toggle, and remove the redundant writes.
• Re-evaluate whether the #1922 workaround is still required against current Lagoon, and drop it if the upstream bug is resolved.

Context

The current implementation lives in .vortex/tooling/src/vortex-deploy-lagoon (rebuilt on the native lagoon CLI in #2764).