fix(api-gateway): preserve gRPC error semantics instead of collapsing to HTTP 500

[pranav8764]

Problem

A repository added through the archiatros-sre GitHub App never appears in the frontend. One reason the bug stayed invisible: the API gateway collapsed every gRPC error from the Integration Service into an indistinguishable HTTP 500 (or 502), so the browser could not tell "this installation belongs to a different GitHub App, reconnect it" from "the database is down".

api-gateway: "list repositories failed","error":"rpc error: code = Internal desc = failed to authorize with github"
api-gateway: GET /api/v1/workspaces/.../integrations/github/installations/.../repositories status=500

Change

Adds a shared resolveGRPCError / writeGRPCError pair in services/api-gateway/internal/handler/integration.go that maps the gRPC status codes the Integration Service uses deliberately onto real HTTP statuses and stable, machine-readable error codes:

gRPC code	HTTP	error code
FailedPrecondition	409	INSTALLATION_REVOKED
NotFound	404	NOT_FOUND
PermissionDenied	403	FORBIDDEN
Unauthenticated	401	UNAUTHORIZED
InvalidArgument	400	INVALID_REQUEST
Unavailable	503	UPSTREAM_UNAVAILABLE
anything else	each handler's existing default	each handler's existing code

Applied to eight handlers: CreateGitHubInstallSession, ListConnectedRepositories, GitHubConfig, GitHubCallback, ListInstallations, ListRepositories, AttachRepository, and GetRepository.

ListConnectedRepositories is the one that closes the loop on the user's report — it backs the dashboard's repository list, on both its workspace-scoped and cross-workspace routes. Paired with #4, a connection orphaned by GitHub App rotation now reaches the browser as an actionable 409 INSTALLATION_REVOKED instead of an opaque 502.

Notes

• No behaviour regressions. Unmapped codes fall through to each handler's pre-existing status and error-code string, so CreateGitHubInstallSession and ListConnectedRepositories still default to 502 and the rest still default to 500.
• Independently mergeable. This is a mapping only, in no particular order with feat(db): bind GitHub installations to their App, allow revoked repo connections #3/fix(integration): detect GitHub App rotation, and revoke what it orphaned #4/fix(frontend): show why a repository never appeared, not an empty dropdown #5. It is correct whether or not the Integration Service already returns codes.FailedPrecondition for a foreign-App installation.
• No credential leakage. Every mapped code carries a fixed message of our own. Upstream error text can embed installation tokens, webhook signatures, or raw GitHub response bodies, so err.Error() is never forwarded to the client. The existing structured slog logging at each call site is unchanged.
• Uses the existing writeError / writeJSON envelope; no new response shape.
• Deliberately left alone: UpsertLogProvider (400), ListLogProviders (502), GitHubWebhook (401), and DecideFixApproval (409) keep their hand-picked statuses. They already return FailedPrecondition for unrelated conditions ("approval has expired", "provider credential encryption is not configured"), which the INSTALLATION_REVOKED label would misdescribe.

Testing

Table-driven tests in services/api-gateway/internal/handler/integration_test.go cover every mapped gRPC code, the default fall-through for all eight handlers, FailedPrecondition -> 409 across all eight, both ListConnectedRepositories routes, wrapped status errors, and plain non-status errors. Each case also asserts that no upstream text (ghs_secret_token, a postgres:// DSN, rpc error) reaches the response body.

cd services/api-gateway && go vet ./... && go test ./...   # pass
make test                                                  # all five Go services pass

make test also runs the Python suites; ai-worker fails locally with No module named pytest, a pre-existing environment gap unrelated to this change.

Browser e2e was intentionally skipped here — #5 owns that flow and only one stack exists on the dev machine.

🤖 Generated with Claude Code