feat: add Forgejo and Gitea SDK client skeletons

[mariusvniekerk]

Introduces separate SDK-backed Forgejo and Gitea clients with host-scoped auth and rate-tracking hooks before shared read behavior is added.

[mariusvniekerk]

This change is part of the following stack:

• docs: plan Forgejo provider implementation #265
  • feat: add Forgejo and Gitea SDK client skeletons #267 ◀
    • feat: share Forgejo and Gitea provider core #268
      • feat: convert Forgejo and Gitea SDK records #269
        • feat: read Forgejo and Gitea through shared provider core #270
          • feat: start Forgejo and Gitea providers at runtime #271
            • feat: recognize Forgejo and Gitea provider configuration #266
              • test: cover Forgejo and Gitea repository imports #272
                • feat: expose Forgejo and Gitea repository imports #273
                  • test: add Forgejo and Gitea container fixtures #274
                  • feat: enable proven Forgejo and Gitea mutations #275
                  • docs: document Forgejo and Gitea setup #276
                  • feat: add gitealike Actions CI parity #281

_{Change managed by git-spice.}

[roborev-ci]

roborev: Combined Review (f1afe5a)

High-level verdict: one blocking reliability issue remains around unbounded Gitea/Forgejo SDK HTTP calls.

High

• internal/platform/forgejo/client.go:70, internal/platform/gitea/client.go:67
  • opts.foregroundTimeout is stored but never applied to the SDK HTTP client. The default http.Client has no timeout, and SDK calls such as version probing and repository lookups can hang indefinitely if the network stalls or the server stops responding.
  • Fix: configure an *http.Client with Timeout: opts.foregroundTimeout and pass it to the SDK via SetHTTPClient, preserving the rateTrackingTransport wrapper when rate tracking is enabled.

Medium

• internal/platform/gitea/client.go:114, internal/platform/forgejo/client.go:116
  • getRepositoryRaw accepts a context.Context, but cancellation is only checked before starting the SDK call. Once GetRepo is in flight, context cancellation or deadlines will not abort the HTTP request.
  • Fix: use a context-aware SDK request path if available, or ensure SDK requests are bound to a configured HTTP timeout/client so sync and foreground operations cannot block indefinitely.

---

Synthesized from 3 reviews (agents: codex, gemini | types: default, security)

[roborev-ci]

roborev: Combined Review (afbb625)

No Medium-or-higher findings were reported across the reviews.

All agents agree the diff is clean for reportable issues.

---

Synthesized from 3 reviews (agents: codex, gemini | types: default, security)

[roborev-ci]

roborev: Combined Review (a2d4236)

Context cancellation is not fully propagated through new Gitea/Forgejo repository fetches.

Medium

• internal/platform/gitea/client.go:104, internal/platform/forgejo/client.go:107
getRepositoryRaw accepts a context.Context, but only checks it before starting the SDK request. If the context is canceled while the HTTP call is in flight, the request can continue until the client timeout expires, delaying sync shutdown or cancellation by up to 20 seconds per request.

  Use a context-aware SDK request path if available, or thread the context into the HTTP request/transport so cancellation aborts the in-flight request.

---

Synthesized from 3 reviews (agents: codex, gemini | types: default, security)

[roborev-ci]

roborev: Combined Review (36dc8ee)

Medium concern: Forgejo/Gitea repository lookups may ignore caller cancellation during SDK requests.

Medium

• internal/platform/gitea/client.go:115, internal/platform/forgejo/client.go:118
  • getRepositoryRaw accepts a context.Context, but only checks it before calling the SDK. Once GetRepo starts, caller cancellation or a shorter deadline may be ignored until the fixed http.Client.Timeout expires, which can make shutdowns or foreground operations hang longer than requested.
  • Fix by ensuring SDK requests use the caller context, or by wrapping the HTTP client/transport so the per-call context is applied to outbound requests. Add a test that cancels the context while the server is still handling the request.

---

Synthesized from 3 reviews (agents: codex, gemini | types: default, security)

[roborev-ci]

roborev: Combined Review (6a59cce)

No Medium, High, or Critical issues found.

All available review outputs are clean or contain no reportable findings.

---

Synthesized from 3 reviews (agents: codex, gemini | types: default, security)

[roborev-ci]

roborev: Combined Review (60e788d)

Medium: withRequestContext can block canceled requests behind an in-flight SDK request.

Medium

• internal/platform/gitea/client.go:119, internal/platform/forgejo/client.go:122
  • withRequestContext checks ctx.Done() before acquiring requestContextMu, but requestContextMu.Lock() is not cancelable.
  • Because the lock is held across the SDK request, a canceled request waiting behind another in-flight request can remain blocked until that unrelated request completes or times out.
  • Replace the mutex with a context-aware lock, such as a size-1 buffered channel or semaphore acquired with select on ctx.Done(). Add a test that cancels while waiting behind an in-flight request.

Security review found no exploitable issue.

---

Synthesized from 3 reviews (agents: codex, gemini | types: default, security)

[roborev-ci]

roborev: Combined Review (6b3cc25)

No Medium, High, or Critical issues found.

All reviewers reported no actionable findings.

---

Synthesized from 3 reviews (agents: codex, gemini | types: default, security)