fix(git-providers): fall back to the page length when GitLab omits x-total

[pedrofrxncx]

Bug found while hardening apps/api/src/git-providers/gitlab/* (GitLab provider client area).

Payoff: GitlabContentClient.searchBranches powers the branch picker (apps/web/src/components/thread/github/use-branches.ts) via totalCount. On a self-hosted or very large GitLab project, GitLab omits the x-total header (documented in this function's own comment as a known case), and the returned page's length is meant to be the fallback. But Number(res.headers.get("x-total")) on a missing header is Number(null) = 0, not NaN — so Number.isFinite(total) was true and the function reported a real total of 0 while still returning actual branches, exactly backwards from the documented intent.

Failure scenario: searching branches on a project large enough that GitLab stops counting matches renders as "0 results" in the branch picker even though branches were returned.

Fix: extracted the header parsing into a small pure totalCountFromHeader(headerValue, fallback) helper that distinguishes an absent header from a present-and-zero one, and unit-tested it directly (matching this file's existing pattern of testable pure helpers like mapCompareDiff/parseChangesCount).

Verify: bun test apps/api/src/git-providers/gitlab/content.test.ts

Checks run locally: bun run fmt, cd apps/api && bunx tsc --noEmit (clean), the targeted test file above (51 pass), bunx oxlint on both touched files (0 warnings/errors). Full CI validates the rest.

---

Summary by cubic

Fixes the GitLab branch picker showing 0 results on large projects by correctly falling back to the page length when GitLab omits the x-total header. Previously a missing header was read as 0 (via Number(null)), so searchBranches reported a total of 0 while still returning branches; now an absent or unparseable header uses the returned branches' length.

• Extracts the header parsing into a small totalCountFromHeader helper and adds unit tests for it.

^{Written for commit b7263f7. Summary will update on new commits.}

[pedrofrxncx]

Closing as stale: this PR sat past the bot's 48h merge window, main has moved on, and its CI results no longer reflect the current base. This is a housekeeping close, not a rejection of the change — if the underlying problem still exists, the bot will find it again and open a fresh, rebased PR.

[studio-bot:stale-close]