Add Connect to Gitea button

[HarshMN2345]

Summary

• Adds a "Connect to Gitea" button alongside the existing "Connect to GitHub" one, so Gitea installations (from feat: add Gitea VCS provider via adapter-driven Vcs\Factory appwrite#12820) can be QA'd locally through the console.
• Gated behind _APP_VCS_PROVIDERS (server-side config) containing gitea — stays hidden unless Gitea is actually configured, no behavior change for GitHub-only environments.
• Ships a stand-in monochrome icon (IconGitea.svelte) since no Gitea icon exists in @appwrite.io/pink-icons-svelte yet; can be swapped once a proper brand icon is added to the shared package.

Test plan

• prettier --check on changed files
• svelte-check — no new errors introduced (pre-existing errors elsewhere unrelated)
• Manual QA against a local Gitea instance once feat: add Gitea VCS provider via adapter-driven Vcs\Factory appwrite#12820 is available

🤖 Generated with Claude Code

just for testing not gonna be live

[greptile-apps]

Greptile Summary

This PR adds a "Connect to Gitea" button to the VCS connection UI, gated behind a new _APP_VCS_PROVIDERS server-side config field that isn't yet in the SDK-generated types.

• git.ts: connectGitHub is refactored into a shared connectVcsProvider(provider, callbackState) helper; both connectGitHub and new connectGitea delegate to it. Clean refactor with no behavioral change for GitHub.
• connectGit.svelte: Reads _APP_VCS_PROVIDERS via a TypeScript type assertion (noted as a temporary workaround) and renders the Gitea button only when 'gitea' is present in that list. The approach is consistent with how isVcsEnabled is handled.
• IconGitea.svelte: A local stand-in SVG icon using currentColor fill, matching the convention of other Icon* components, to be replaced once a proper brand icon lands in the shared package.

Confidence Score: 4/5

Safe to merge for GitHub-only environments; the Gitea flow is unreachable until the backend PR ships and _APP_VCS_PROVIDERS is populated

The changes are small and well-scoped. The one open question is whether _APP_VCS_PROVIDERS arrives from the server as an array or a string; the includes logic works differently in each case, and that has not been validated yet since the companion backend PR is not merged.

connectGit.svelte — the _APP_VCS_PROVIDERS type assertion and runtime behavior should be confirmed against the actual API response shape once the backend is available

Important Files Changed

Filename	Overview
src/lib/stores/git.ts	Refactors connectGitHub into a shared connectVcsProvider helper and adds connectGitea; clean and correct
src/lib/components/git/connectGit.svelte	Adds Gitea button gated by _APP_VCS_PROVIDERS; uses a type assertion cast since the field isn't in the SDK types yet, with a runtime type assumption worth verifying
src/lib/components/git/IconGitea.svelte	New stand-in SVG icon following the existing currentColor convention; straightforward

Prompt To Fix All With AI

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

---

### Issue 1 of 1
src/lib/components/git/connectGit.svelte:14-16
**`_APP_VCS_PROVIDERS` runtime type assumption** — The cast to `{ _APP_VCS_PROVIDERS?: string[] }` is erased at runtime, so `vcsProviders.includes('gitea')` dispatches to whatever prototype the server actually returns. If the server sends a comma-separated string (`"github,gitea"`), `String.prototype.includes` will do a substring check instead of an exact-element check — which happens to work for `'gitea'` but would produce false positives for values like `"notgiteahere"` or future provider names that are substrings of one another. Could you confirm the API response shape is already `string[]`, or add a defensive runtime check?

_{Reviews (1): Last reviewed commit: "Add a Connect to Gitea button alongside ..." | Re-trigger Greptile}

[greptile-apps]

_APP_VCS_PROVIDERS runtime type assumption — The cast to { _APP_VCS_PROVIDERS?: string[] } is erased at runtime, so vcsProviders.includes('gitea') dispatches to whatever prototype the server actually returns. If the server sends a comma-separated string ("github,gitea"), String.prototype.includes will do a substring check instead of an exact-element check — which happens to work for 'gitea' but would produce false positives for values like "notgiteahere" or future provider names that are substrings of one another. Could you confirm the API response shape is already string[], or add a defensive runtime check?

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/lib/components/git/connectGit.svelte
Line: 14-16

Comment:
**`_APP_VCS_PROVIDERS` runtime type assumption** — The cast to `{ _APP_VCS_PROVIDERS?: string[] }` is erased at runtime, so `vcsProviders.includes('gitea')` dispatches to whatever prototype the server actually returns. If the server sends a comma-separated string (`"github,gitea"`), `String.prototype.includes` will do a substring check instead of an exact-element check — which happens to work for `'gitea'` but would produce false positives for values like `"notgiteahere"` or future provider names that are substrings of one another. Could you confirm the API response shape is already `string[]`, or add a defensive runtime check?

How can I resolve this? If you propose a fix, please make it concise.

[HarshMN2345]

@greptile Confirmed against the actual server code _APP_VCS_PROVIDERS is declared with 'array' => true in ConsoleVariables.php, and Appwrite's response serialization (Response.php:562) explicitly throws if that field isn't a real PHP array before encoding. So it's guaranteed to be a JSON array on the wire, never a comma-joined string — .includes('gitea') correctly dispatches to Array.prototype.includes. No substring-match risk here.

[greptile-apps]

Thanks for digging into that — the 'array' => true declaration and the serialization guard in Response.php are exactly the kind of server-side guarantees that make the type cast safe. The concern is fully resolved; no changes needed here.