feat: add GitHub Action usage metrics for telemetry

[cocosheng-g]

Description

This PR implements the necessary infrastructure in the `run-gemini-cli` GitHub Action to support the Gemini CLI usage metrics (P0 requirements).

It aligns with the core CLI telemetry changes introduced in google-gemini/gemini-cli#21129.

Changes Made:

• Strongly-Typed Telemetry Tracking: Replaced the generic `github_item_number` with three specific inputs: `github_pr_number`, `github_issue_number`, and `github_custom_tracking_id`. This ensures that Pull Requests, Issues, and custom batch IDs are logged to distinct fields, providing maximum accuracy for downstream analytics without overlapping ID spaces.
• Installation Telemetry: Added `GH_WORKFLOW_NAME`, `GH_PR_NUMBER`, `GH_ISSUE_NUMBER`, and `GH_CUSTOM_TRACKING_ID` to the `Install Gemini CLI` step to ensure extension installations are properly tracked.
• OTEL Collector Enhancement: Updated the `scripts/collector-gcp.yaml.template` to include specific resource attributes for `github.pr.number`, `github.issue.number`, and `github.custom_tracking.id`.
• Example Workflow Updates: Updated all example workflows (Review, Triage, Assistant, Scheduled Triage) to explicitly pass the correct IDs to the action, improving clarity and ensuring accurate telemetry.

Example Telemetry Scenarios

Because the CLI appends these context fields to the `baseMetadata` of all events (API Request, Response, Error), downstream analytics can perfectly distinguish and count unique issues vs. PRs based on the specific fields.

Scenario A: Automated PR Review

When PR 42 triggers the `gemini-review` workflow, the CLI logs:

{
  \"event_name\": \"api_request\",
  \"event_metadata\": [
    [
      { \"gemini_cli_key\": 130, \"value\": \"gemini-review\" },
      { \"gemini_cli_key\": 172, \"value\": \"pull_request\" },
      { \"gemini_cli_key\": 173, \"value\": \"42\" } // GH_PR_NUMBER
    ]
  ]
}

Analysts can count `DISTINCT gh_pr_number WHERE gh_workflow_name LIKE '%review%'` to satisfy the P0 PR metric.

Scenario B: Automated Issue Triage

When Issue 88 triggers the `gemini-triage` workflow, the CLI logs:

{
  \"event_name\": \"api_request\",
  \"event_metadata\": [
    [
      { \"gemini_cli_key\": 130, \"value\": \"gemini-triage\" },
      { \"gemini_cli_key\": 172, \"value\": \"issues\" },
      { \"gemini_cli_key\": 174, \"value\": \"88\" } // GH_ISSUE_NUMBER
    ]
  ]
}

Analysts can count `DISTINCT gh_issue_number WHERE gh_workflow_name LIKE '%triage%' AND gh_event_name = 'issues'` to satisfy the P0 Automated Issue metric.

Scenario C: Scheduled Batch Triage

When a cron job runs and triages 3 issues (IDs 101, 102, 103) in a single CLI invocation, the CLI logs:

{
  \"event_name\": \"api_request\",
  \"event_metadata\": [
    [
      { \"gemini_cli_key\": 130, \"value\": \"gemini-scheduled-triage\" },
      { \"gemini_cli_key\": 172, \"value\": \"schedule\" },
      { \"gemini_cli_key\": 175, \"value\": \"101,102,103\" } // GH_CUSTOM_TRACKING_ID
    ]
  ]
}

Analysts can split the `gh_custom_tracking_id` string by commas to count exactly 3 unique issues processed during a scheduled invocation.

Related Issues

• Fixes P0 metrics requirements for GitHub Action usage.
• Depends on google-gemini/gemini-cli#21129

[gemini-cli]

🤖 Hi @cocosheng-g, I've received your request, and I'm working on it now! You can track my progress in the logs for more details.