feat(developer): manage the GitHub account from a developer rail

[vladjerca]

Why

Connecting GitHub now happens once per account rather than per app, so it no longer belongs on the create form. This moves it to a Developer panel beside the apps grid, the "profile rail" option from the design exploration.

What changes

• Developer rail (DeveloperRail.svelte) beside the apps grid, in three states:
  • Not connected, no apps: a Connect GitHub prompt.
  • Not connected, has apps: the same prompt in an attention colour, saying the existing apps keep working. The apps stay listed, viewable and editable as normal. Only creating is locked.
  • Connected: the handle and GitHub id, an "App limit reached" badge only once the account is at its limit, Re-verify, Switch GitHub account, and Unlink.
• Unlink asks for the GitHub handle to be typed, the same inline pattern the page already uses for deleting an app. It states how many apps it will delete.
• Creating is gated. The create tile and the header button only appear for a linked account under its limit. Otherwise the tile is locked and says why ("Connect GitHub first", or "App limit reached"). /apps/new runs the same check and redirects to My Apps for an unlinked account or one at its limit, so the form is never reachable when creating would fail.
• The create form loses its Connect block and says which verified account the app is being created under.
• Switching accounts is chosen before the GitHub redirect. A GitHub code works only once, so asking after GitHub returns would mean holding the verified identity between two requests. The intent is stored alongside the OAuth state and sent as switch: true.
• The apps list does not depend on the profile. The apps and the profile load independently, so a failed profile request shows the error with Retry while the existing apps stay listed and editable.
• Unlink clears the deleted state straight away. Once the DELETE succeeds, the apps and the identity are cleared before the refresh, so a failed refresh cannot show deleted apps next to the success notice.
• The GitHub callback is handled in Applications.svelte, which has the account slot the API call needs, so routes/(portal)/apps/+page.svelte goes back to rendering the page, like the new route.

Error codes are localized on the client

The API now answers every developer and applications error with a stable snake_case code in error, for example github_account_taken, instead of an English sentence. developerErrorMessage.ts maps each code to the portal's own copy, and accountRequest uses it for every status. An unknown code, a non-string value or a plain-text body falls back to the existing per-status copy.

That keeps the portal's rule that server output is never shown to the user: the portal only ever displays text it owns. The existing does not echo error bodies or credentials spec still passes unchanged, and a new one checks that a server sentence is not shown even inside a JSON error.

developerErrorMessage.spec.ts lists every code the API can return and checks each has copy, so a code added on the API side without portal copy shows up as a missing entry there. The portal has no translation layer today, so the copy is English, but it now lives in one table ready for one.

The generic 400 copy also changes from a GitHub-specific message to a neutral one, because most 400s here are about app details, not GitHub.

Depends on

The API change that adds GET /v3/users/me/developer and PUT and DELETE on /v3/users/me/developer/github. It has to be live first: until then the rail cannot load and the create tile stays locked for everyone.

Checks

• deno fmt --check --config deno.json passes
• deno task format:svelte:check passes
• deno task check: 369 files, 0 errors, 0 warnings
• deno lint passes
• deno task test: 198 tests passed. New specs for developerProfile.ts, the rewritten githubConnect.ts, copy for every error code, and the error-message boundaries

Not verified end to end

As with #945, the portal hardcodes https://api.trakt.tv (#947), and the new endpoints are not deployed yet, so this cannot be exercised locally against a real API. It is covered by unit specs and should be smoke tested on production once the API change ships.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 8409056317

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".