Scale the integration test watchdog up under the race detector

The integration test watchdog fails a test if its recording takes longer
than 40 seconds. Under the race detector everything runs several times
slower, so legitimately slow tests (e.g. a conflicting interactive
rebase) blow that budget and fail even though nothing is actually stuck.

Key the timeout off a build-tag constant: the `race` tag is set
automatically when the binary is built with -race, so a race build gets
a 5x-longer budget while a normal build is unchanged, and the two can't
drift apart the way a runtime flag would. The base 40s stays in one
place; only the multiplier varies by build.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

pkg/gui/test_mode.go

@@ -45,9 +45,10 @@ func (gui *Gui) handleTestMode() {
 		}()
 
 		if os.Getenv(components.WAIT_FOR_DEBUGGER_ENV_VAR) == "" {
+			timeout := 40 * time.Second * testTimeoutMultiplier
 			go utils.Safe(func() {
-				time.Sleep(time.Second * 40)
-				log.Fatal("40 seconds is up, lazygit recording took too long to complete")
+				time.Sleep(timeout)
+				log.Fatalf("%v is up, lazygit integration test took too long to complete", timeout)
 			})
 		}
 	}

pkg/gui/test_timeout_norace.go

@@ -0,0 +1,5 @@
+//go:build !race
+
+package gui
+
+const testTimeoutMultiplier = 1

pkg/gui/test_timeout_race.go

@@ -0,0 +1,10 @@
+//go:build race
+
+package gui
+
+// The race detector makes everything run several times slower, so the
+// recording watchdog needs a correspondingly longer timeout; otherwise it
+// fires on tests that are merely slow under -race rather than actually stuck.
+// The `race` build tag is set automatically when the binary is built with
+// -race, so this can't drift out of sync with the actual build.
+const testTimeoutMultiplier = 4