feat: add Gitea source-control provider - #8232

💭 I'm reviewing the current state of GiteaCli.ts to check whether prior review comments were addressed—confirming that the execution error context now correctly makes status and cause optional, the decode error context requires cause, and checking how GiteaPullRequestDecodeError handles the reference and operation fields. I'm also examining listPage's JSON parsing logic, noting there's some redundancy in parsing twice to compute rawCount before decoding with decodeGiteaPullRequestListJson, though this does address the earlier suggestion to derive rawCount from the parsed value rather than a hand-rolled check. I'm also glancing at the import style to confirm type-only imports are used appropriately. Now I'm checking the error mapping in GiteaSourceControlProvider, where detail comes from a static getter on the error class rather than copying cause.message, which seems consistent with the guidance and likely matches how GitHub and GitLab providers handle their own error mapping. I want to verify that consistency by comparing against the existing GitHubSourceControlProvider implementation, and I'm also confirming the discovery spec object correctly satisfies its type with properly named imports. I'm also scanning for uses of Effect.catchIf or catchTag patterns, checking the VcsProcess.ts diff for anything unusual, and looking at whether Layer.mock usage in tests is acceptable. Finally I want to double-check the actual head file state since the diff is relative to the merge base and the PR may have moved since.

1. browse_code — apps/server/src/sourceControl/GiteaCli.ts

2. browse_code — apps/server/src/sourceControl/GitLabCli.ts

💭 The Gitea implementation now looks conventional and the prior findings seem addressed. I'm checking the remaining possible issues: the hand-rolled JSON.parse in listPage is duplication rather than a listed convention violation, and I'm verifying whether GiteaPullRequestListDecodeError's required cause field is properly typed. I confirm giteaCliExecutionErrorContext's optional cause field is justified, and check that no redundant single-value discriminator exists in GiteaRepositoryDecodeError since operation remains diagnostic-only. I look at whether detail fields copy cause messages versus using static strings, finding GiteaSourceControlProvider consistent with GitLab's existing pattern, and note GitManager.test.ts's acceptance of service instances as test parameters is fine. I check the web app files for Effect usage, confirm the schemaJson imports and re-exported formatGiteaJsonDecodeError alias look consistent with gitLabMergeRequests.ts, though I want to verify whether that alias is actually used anywhere or is dead code. I also verify GiteaCli's execute member exposure mirrors other CLI service interfaces, and check the discovery spec's refineUnknownRemote return shape and GiteaSourceControlProvider's discovery logic for consistency.

3. git_tools — formatGiteaJsonDecodeError|formatGitLabJsonDecodeError

4. git_tools — Layer.succeed|ManagedRuntime.make|runPromise

💭 The unused alias mirrors existing dead code in GitLab too, so it's not worth flagging as a new convention violation. Now I want to check the other changed files in apps/web for import conventions, glance at GitActionsControl.tsx and the projects operations file, and then move on to SourceControlPro. Looking at the registry change, it acquires the Gitea provider via yield* GiteaSourceControlProvider.make inside the registry's own make function — I need to confirm this matches the pattern used for the other providers in that same file.

5. browse_code — apps/server/src/sourceControl/SourceControlProviderRegistry.ts

6. browse_code — apps/server/src/sourceControl/GiteaSourceControlProvider.ts

💭 The web-side changes look like standard UI updates following existing conventions. I want to double-check the import style in GitActionsControl.tsx since it uses Option from Effect, just to make sure it matches the codebase's usual pattern.

7. git_tools — from "effect"

💭 Tests look solid across GiteaCli, provider, logins, and contracts, and prior findings seem addressed, so the review looks clean. I need to reconcile the "All clear" instruction with the required JSON schema output—I'll place "All clear" within the summary field while keeping the structure valid.