fix(balancer): stop execution after intermediate team provisioning failures

[youknowme19]

Summary

This PR fixes an issue where the balancer's team provisioning handlers continued executing subsequent resource provisioning steps after an intermediate failure. The change ensures that execution stops immediately after an error response is sent, preventing duplicate HTTP responses and unnecessary Kubernetes API calls.

Closes #1286

Problem

During team creation, the balancer provisions multiple Kubernetes resources sequentially, including namespaces, ConfigMaps, Secrets, deployments, roles, and role bindings.

If one of the intermediate provisioning steps fails, the corresponding error handler returns a 500 Internal Server Error response but continues executing the remaining provisioning logic. As a result:

• Additional provisioning steps continue unnecessarily after the request has already failed.
• The handler eventually attempts to send a success response, resulting in ERR_HTTP_HEADERS_SENT errors.
• Unnecessary Kubernetes API calls are made after a failed provisioning step.

This affects the following handlers in wrongsecrets-balancer/src/teams/teams.js:

• createTeam
• createAWSTeam
• createAzureTeam
• createGCPTeam

Root Cause

The error handlers for intermediate provisioning steps send an error response but do not terminate the request handler, allowing execution to continue through the remaining provisioning steps.

Solution

Terminate the request handler immediately after sending an error response during any intermediate provisioning failure.

This ensures that:

• No additional provisioning operations are executed after a failure.
• Only a single HTTP response is sent for each request.
• ERR_HTTP_HEADERS_SENT errors are avoided.

Testing

• Added a regression test covering namespace creation failure.
• Verified that subsequent provisioning functions are not executed after the failure.
• Ran npm test successfully (38 tests passed).
• Ran npm run lint successfully (no linting issues).

Checklist

• My code follows the project's coding style.
• I have added or updated tests to cover the change.
• All new and existing tests pass.
• Lint checks pass successfully.