limiter: Treat gitlab-kas as an internal concurrency client

What does this MR do and why?

Since 16c67a12 (limiter: Exempt internal clients from unauthenticated limits), a request that carries no end-user username is routed to the unauthenticated concurrency budget unless its client_name is in internal_clients, which defaults to ["gitlab-sidekiq"].

gitlab-kas (the agent server) also calls Gitaly without an end-user username — for GitOps manifest syncs — but it is token-authenticated internal traffic, exactly the case useUnauthenticatedLimiter describes. Because it wasn't in the default list, it was limited as anonymous public access: on GitLab.com, agent LastCommitForPath calls were ~66% of all LastCommitForPath ResourceExhausted rejections on the fleet in a 24h window, in bursts on individual GitOps repos.

This adds gitlab-kas to defaultInternalClients so every installation treats the agent server as internal.

Closes #7459 (closed).

How

defaultInternalClients becomes ["gitlab-sidekiq", "gitlab-kas"]. Installations that set internal_clients explicitly are unaffected; only the unset default changes. Scoped to adding gitlab-kas (Proposal 1 in the issue); whether other first-party servers (gitlab-shell, workhorse, zoekt, ES indexer) should also be default, or the default redesigned, is left as a separate decision (Proposal 2).

Test coverage

TestLoadInternalClients "default value" now asserts ["gitlab-sidekiq", "gitlab-kas"] — the default when internal_clients is unset. It fails before the change and passes after. The "explicit override" and "empty list disables the exemption" cases are unchanged, pinning that an explicit config still wins and an empty list still disables the exemption.