refactor(forges): route OAuth-app validators through the adapter

[afonsojramos]

Summary

Follow-up to #2874. routes/LoginWithOAuthApp.tsx imported getNewOAuthAppURL, isValidClientId, isValidToken directly from forges/github/auth. The route is already forge-aware (it pulls forge from route state), but the validators and the "Create new OAuth App" link bypassed the adapter.

• Add validateOAuthClientId?(id): boolean and getNewOAuthAppUrl?(hostname): Link to ForgeAdapter. Both optional — forges without OAuth-app support omit them.
• Wire on the GitHub adapter (isValidClientId, getNewOAuthAppURL).
• validateForm(values, forge) now dispatches through getAdapter(forge). Client-secret format check reuses adapter.validateToken since GitHub's client-secret format happens to match its PAT format.
• "Create new OAuth App" button hides when the active adapter doesn't expose getNewOAuthAppUrl.

Test plan

• pnpm exec tsc --noEmit — clean
• pnpm lint — clean
• pnpm exec vitest --run src/renderer/routes/LoginWithOAuthApp.test.tsx src/renderer/utils/forges/github/adapter.test.ts — passes

[setchy]

Instead of ForgeAdapter being flat with many optional, but related functions needed an implementation... Could we encapsulate this differently?

ie: if a forge adapter implementats the OAuth flow then it needs to implement the 3-4 funds. Similarly for PATs and other "groupable" interface fns

[afonsojramos]

oOoOoOo I like that 👀

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
87.9% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud