fix(integrations): Fix "Update in GitHub" flow

[Twixes]

What's broken

If you already have GitHub connected and hit "Update in GitHub" in Code settings, it wasn't doing the right thing. It kicked off a fresh connect flow instead of taking you to your existing app installation. And when you came back after changing repo access on GitHub, Code didn't reliably pick up the update (esp. the setup_action=update path where GitHub doesn't send state).

What this fixes

"Update in GitHub" now opens the correct GitHub installation settings page (org installs vs personal installs are different URLs), and sets up the callback so PostHog knows to finish setup when you return. You land back in Code with refreshed integration state. Initial "Connect GitHub" is unchanged..

Needs PostHog/posthog#58951 on the backend for the return trip to actually work end-to-end.

[greptile-apps]

Prompt To Fix All With AI

Fix the following 3 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 3
apps/code/src/renderer/features/settings/components/sections/GitHubIntegrationSection.tsx:48-52
**Silent failure gives no user feedback**

When `prepareGithubTeamIntegrationCallback` throws, the `catch` block silently returns. The user clicks "Update in GitHub" and nothing happens — no GitHub tab opens, no error message appears. At minimum the error should be surfaced (e.g. a toast), otherwise users are left believing the click registered when it didn't.

### Issue 2 of 3
apps/code/src/renderer/features/integrations/utils/githubInstallationSettingsUrl.test.ts:26-51
Three distinct input/output cases are bundled in a single `it` with multiple `expect` calls. The project explicitly prefers parameterised tests — if the first assertion fails the remaining cases are never run, making it harder to pinpoint regressions. Using `it.each` gives each case an independent result and a descriptive name.

```suggestion
describe("resolveGithubInstallationId", () => {
  it.each([
    [
      "prefers top-level installation_id over integration_id and config",
      { id: 99, kind: "github", installation_id: "a", config: { installation_id: "c" } },
      "a",
    ],
    [
      "falls back to integration_id when installation_id is absent",
      { id: 1, kind: "github", integration_id: 12345 },
      "12345",
    ],
    [
      "falls back to config.installation_id as last resort",
      { id: 1, kind: "github", config: { installation_id: "c" } },
      "c",
    ],
  ])("%s", (_label, input, expected) => {
    expect(resolveGithubInstallationId(input as Parameters<typeof resolveGithubInstallationId>[0])).toBe(expected);
  });
});
```

### Issue 3 of 3
apps/code/src/renderer/api/posthogClient.ts:664
Redundant status guard — `response.ok` is already `true` for every 2xx response including 204, so `&& response.status !== 204` can never change the outcome of the outer `!response.ok` check. Per simplicity rule 4, this is a superfluous part.

```suggestion
    if (!response.ok) {
```

_{Reviews (1): Last reviewed commit: "feat(integrations): wire github finish s..." | Re-trigger Greptile}

[charlesvien]

I'm getting reports of this from external users as well