build(deps): bump sentry-go to 0.50.0 and gate on IsEnabled

[SyniRon]

Summary

This takes the sentry-go 0.49.0 → 0.50.0 bump from Dependabot's #271 and fixes what it breaks. In 0.50.0 the hub holds a disabled no-op client where it used to hold nil. Both "is Sentry off?" guards in rest checked for nil, so they stopped firing.

 sentryMiddleware(next)
-  if CurrentHub().Client() == nil        # never true on 0.50.0
+  if !sentryCaptureEnabled()             # CurrentHub().Client().IsEnabled()
     pass through untouched
   recover panic, capture event, write 500

 FlushSentryOnShutdown()
-  if CurrentHub().Client() == nil
+  if !sentryCaptureEnabled()
     warn and skip the signal handler
   install flush-on-signal handler

Test changes:

• Assertions on a nil client now check IsEnabled().
• Two preconditions that only repeated the behavior assertions are gone.
• The flush-guard test checks that a warning was logged, not its wording.
• Two test names and the "no client" comments now talk about capture being off.

Evidence

• Before: build(deps): bump github.com/getsentry/sentry-go from 0.49.0 to 0.50.0 #271's CI, on 0.50.0 with the nil guards. Five tests fail in rest:

  SENTRY_DSN unset, handler panics "ranks exploded"
    middleware recovers it and writes a 500
    TestSentry_NoDSNIsCompletePassThrough                      FAIL
    TestMetrics_PanickingHandlerMetersAs500AndPanicPropagates  FAIL
  FlushSentryOnShutdown() with no DSN
    installs the handler, logs nothing
    TestFlushSentryOnShutdown_NoClient_WarnsAndSkips           FAIL
  plus two SetupSentry tests asserting Client() == nil         FAIL
  

  After: the panic propagates with nothing written, and the flush guard warns and skips. go vet ./..., go test -race ./... and make test-integration against the MariaDB harness all pass locally. Changing sentryCaptureEnabled back to a nil check fails the pass-through, metrics-panic and flush-guard tests.

Merge Danger

Door: two-way

Reverting this PR restores 0.49.0 and the nil guards. There is no data or schema change.

Blast Radius: telemetry

With SENTRY_DSN set, SetupSentry still initialises an enabled client, so production takes the same capture path as before. TestSetupSentry_DSNEnablesClientWithRelease still sees exactly one event with the release tag. The no-DSN path, which local and dev runs use, is the one 0.50.0 broke, and this keeps it a pass-through. Dependabot should close #271 on its own once develop has 0.50.0.

Refs #271

This was generated by AI