fix: Misc billing, error handling and UX improvements

[charlesvien]

Problem

Assorted fixes across billing, API error handling and pre-auth screens.

Changes

1. Fetch both best seat and org-specific seat to show correct plan per org
2. Harden API fetcher to handle non-JSON error responses
3. Show update banner on pre-auth/full-screen layouts
4. Add billing link to payment error callout
5. Re-fetch seat after org switch in onboarding
6. Add VITE_POSTHOG_ACCESS_TOKEN_OVERRIDE env var for dev/testing
7. Update alpha plan banner copy to clarify free Pro access through June 4, 2026

How did you test this?

Manually

[charlesvien]

• fix: Misc billing, error handling and UX improvements #2014 👈 (View in Graphite)
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[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/api/fetcher.ts:66-72
In HTTP/2 connections (which are standard for modern HTTPS APIs), `response.statusText` is always an empty string per the Fetch spec, so the fallback produces `{"error":""}` — useless for diagnostics. Cloning the response before calling `.json()` lets the catch handler read the raw body text instead, giving actual content for non-JSON error payloads. The same pattern applies to both catch sites.

```suggestion
        } catch {
          const cloned = response.clone();
          const errorResponse = await response
            .json()
            .catch(() => cloned.text().then((t) => ({ error: t || response.statusText })));
          throw new Error(
            `Failed request: [${response.status}] ${JSON.stringify(errorResponse)}`,
          );
```

### Issue 2 of 3
apps/code/src/renderer/api/fetcher.ts:76-82
Same HTTP/2 `statusText` issue as in the 401 retry path above — the fallback will always yield `{"error":""}`. Cloning the response first preserves the body for a text fallback.

```suggestion
      if (!response.ok) {
        const cloned = response.clone();
        const errorResponse = await response
          .json()
          .catch(() => cloned.text().then((t) => ({ error: t || response.statusText })));
        throw new Error(
          `Failed request: [${response.status}] ${JSON.stringify(errorResponse)}`,
        );
```

### Issue 3 of 3
apps/code/src/renderer/features/settings/components/sections/PlanUsageSettings.tsx:243-244
**Hardcoded expiry date will go stale**

The date "June 4, 2026" is hard-coded in the UI copy. Today is 2026-05-04 — that's approximately 30 days away. Once the date passes, users will see text claiming they have free Pro access "until June 4, 2026" even if the plan has been extended, expired, or changed. This should be driven by a value from the API/config so it can be updated without a new release, or at minimum there should be a plan to update this copy before that date.

_{Reviews (1): Last reviewed commit: "Show update indicator on pre-auth screen..." | Re-trigger Greptile}