Expose language_id from Gitaly CommitLanguages response

What does this MR do and why?

Contributes to #519895 (closed)

Problem

The programming_languages table uses an auto-increment id that is inconsistent across GitLab cells. Gitaly already returns a globally stable language_id in CommitLanguagesResponse.Language (added in gitaly!8068 (merged)), but the Rails side discards it.

Solution

Include language_id in the hash returned by Gitlab::GitalyClient::CommitService#languages and add a language_gitaly_id accessor to Gitlab::LanguageDetection so downstream consumers can look up the Gitaly-assigned identifier by language name. This prepares for step 3 of the issue, which will persist this ID in the programming_languages table.

References

• Issue: #519895 (closed)
• Gitaly MR that added language_id to the protobuf response: gitaly!8068 (merged)

Screenshots or screen recordings

Not applicable — backend-only change.

How to set up and validate locally

1. Open a Rails console: bin/rails console
2. Pick a project with a repository: project = Project.find_by_full_path('your/project')
3. Call project.repository.raw_repository.languages and verify each entry now includes a language_id key
4. Verify Gitlab::LanguageDetection exposes the ID:

   project = Project.find_by_full_path('gitlab-org/gitlab-test')
   detection = Gitlab::LanguageDetection.new(project.repository, project.repository_languages)
   detection.language_gitaly_id('Ruby') # => integer or nil

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.