refactor(notifications): generate notification URL via the adapter

[afonsojramos]

Summary

Follow-up to #2874. notifications/url.ts imported getHtmlUrl directly from forges/github/client and called it for every notification — including ones from Gitea accounts. That was a sharp adapter leak.

• Replace the direct getHtmlUrl import with adapter.followUrl<{ html_url: string }>(account, url). The Gitea adapter already implements followUrl (via giteaGetJson), so this works for both forges.
• Rename generateGitHubWebUrl → generateNotificationWebUrl to match what it actually does.
• Drop the now-unused getHtmlUrl helper from forges/github/client.ts plus its test, and the GitHubHtmlUrlResponse type.
• Tests now spy on githubAdapter.followUrl instead of the deleted helper.

Test plan

• pnpm exec tsc --noEmit — clean
• pnpm lint — clean
• pnpm exec vitest --run src/renderer/utils/notifications/url.test.ts src/renderer/utils/forges/github/client.test.ts src/renderer/utils/system/links.test.ts src/renderer/utils/system/native.test.ts — passes

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

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

See analysis details on SonarQube Cloud

[setchy]

Octokit client has inbuilt caching the typing. I wouldn't want to stray from that