Prevent gin.SetMode from causing race conditions

[djeebus]

1. We run all of our tests in parallel.
2. We fail our tests if data race conditions are detected.
3. Many tests call gin.SetMode
4. gin.SetMode writes a global variable
5. Therefore, calling gin.SetMode in multiple tests that run in parallel can cause data race conditions.

This PR removes them and uses the environment variable to gain the same effect. We set GIN_MODE=test when running tests in github actions, and GIN_MODE=release when deploying any jobs.

[cursor]

PR Summary

Medium Risk
Shifts Gin mode configuration from in-process gin.SetMode calls to environment variables, which can change runtime behavior if GIN_MODE is not set correctly in deploy/test environments. CI and Nomad defaults mitigate this, but missing env wiring could lead to unexpected logging/debug behavior.

Overview
Removes all in-code gin.SetMode(...) usage (including test init/TestMain and service startup paths) to avoid race conditions from Gin’s global mode, and instead standardizes mode selection via GIN_MODE (set to test in PR GitHub Actions workflows and defaulted to release for the API Nomad job). Also adds a golangci-lint forbidigo rule to prevent reintroducing gin.SetMode.

^{Reviewed by Cursor Bugbot for commit 9805594. Bugbot is set up for automated code reviews on this repo. Configure here.}

[levb]

LGTM, tests pending

[jakubno]

can we just set it to release mode when starting gin server in code? I don't think there's any benefit for us to use debug ever

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 2a5023b. Configure here.}

[djeebus]

can we just set it to release mode when starting gin server in code? I don't think there's any benefit for us to use debug ever

There is lots of very useful output that gin provides with mode=debug that can help with debugging local issues. It makes perfect sense to run it locally with debug, but disable it when deploying. It can also be useful to turn it on temporarily when deployed, to identify mismatches in paths, routes, requests sent vs requests received, things like that. Seems silly to prevent ourselves from using it when turning it off only when deploying is so simple.