fix: echo the authorize redirect_uri when exchanging the Slack install code

[fclairamb]

The bug

Installing Slack from the dashboard (/dash0/orgs/<org>/integrations/new) fails on production right after the user clicks Allow, bouncing to https://www.solidping.io/saas/install-error?reason=oauth_failed.

Production logs name the cause exactly:

level=ERROR msg="Failed to exchange OAuth code" error="slack API error: bad_redirect_uri"
level=ERROR msg="Slack OAuth exchange failed" error="OAuth exchange failed: slack API error: bad_redirect_uri"

Root cause

BuildInstallURL always sent a redirect_uri on the authorize request, but exchangeCodeAndFetchUser passed "" to oauth.v2.access, with a comment asserting the parameter was optional.

It is optional only when authorize did not use one. When authorize did send one, Slack requires the exchange to echo the identical value and rejects the install otherwise.

Why it went unnoticed

Two reasons, both worth recording:

• Slack login was never affected. auth/slack_service.go:326 passes the callback URL at both ends, so signing in with Slack kept working and masked a completely broken install path. Discord was never affected either — it already funnels both call sites through one installRedirectURI() helper (discord/service.go:256,323).
• No test ever drove a successful exchange. The only other test through this path (TestHandleOAuthCallback_StateConsumedOnReuse) deliberately relies on the exchange failing, and the sole redirect_uri assertion was on the authorize URL. The asymmetry was structurally invisible.

The fix

Both call sites now go through a single installRedirectURI() helper — the same shape Discord and Slack login already use, so they cannot drift again.

Test

TestHandleOAuthCallback_EchoesAuthorizeRedirectURIAtExchange asserts the exchange request, not just the authorize URL. It was confirmed to fail on the old code:

expected: "http://localhost:4000/api/v1/integrations/slack/oauth"
actual  : ""

It also carries a positive control pinning the concrete value, so a helper that returned "" on both sides would still fail.

QA

make build-backend lint-back test — all green (lint 0 issues, full backend suite passing).

Note for the deploy

This is a production fix; prod has silently lagged releases before, so it is worth confirming the running image actually picks this up rather than assuming the tag deployed.

🤖 Generated with Claude Code