Add option to expose git-sync metrics port

[PreethamSanji]

The git-sync sidecar can serve Prometheus metrics via its built-in HTTP server
(GITSYNC_HTTP_METRICS), but the chart provides no way to declare that port on
the container, so the metrics endpoint cannot be discovered or scraped.

This PR adds a dags.gitSync.metrics.enabled option (default false). When
enabled, the git-sync sidecar container gets:

• GIT_SYNC_HTTP_METRICS / GITSYNC_HTTP_METRICS env vars set to "true"
• a named container port gitsync-metrics bound to the existing
  dags.gitSync.httpPort value, so the declared port can never drift from the
  bind address

The init container is unaffected (it runs no HTTP server). With the option
disabled (default), rendered manifests are identical to main.

Rendered output with dags.gitSync.metrics.enabled=true:

            - name: GIT_SYNC_HTTP_METRICS
              value: "true"
            - name: GITSYNC_HTTP_METRICS
              value: "true"
          ports:
            - name: gitsync-metrics
              containerPort: 1234

With default values, no ports section or metrics env vars are rendered
(verified via helm template before/after comparison).

Exposing the metrics via a dedicated Service or scrape annotations is
intentionally left out of scope, per the open design question on the issue —
happy to add it here or in a follow-up based on maintainer preference.

Unit tests added in test_git_sync_scheduler.py covering: port + env rendering
when enabled, port following a custom httpPort, and no rendering by default.

closes: #62592

---

Was generative AI tooling used to co-author this PR?

• Yes (please specify the tool below)
  Claude Fable 5

Generated-by: [Claude Fable 5] following the guidelines

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

[boring-cyborg]

Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contributors' Guide
Here are some useful points:

• Pay attention to the quality of your code (ruff, mypy and type annotations). Our prek-hooks will help you with that.
• In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example Dag that shows how users should use it.
• Consider using Breeze environment for testing locally, it's a heavy docker but it ships with a working Airflow and a lot of integrations.
• Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
• Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
• Be sure to read the Airflow Coding style.
• Always keep your Pull Requests rebased, otherwise your build might fail due to changes not related to your commits.
  Apache Airflow is a community-driven project and together we are making it better 🚀.
  In case of doubts contact the developers at:
  Mailing List: dev@airflow.apache.org
  Slack: https://s.apache.org/airflow-slack