feat: Add Copilot 3rd-party agent metrics

[Tens1des]

Adds totals_by_3rd_party_agent to Copilot usage metrics report structs.

GitHub changelog: https://github.blog/changelog/2026-08-07-copilot-usage-metrics-api-adds-agent-app-activity/

• New CopilotMetricsThirdPartyAgent type (agent_name, agent_id, user_initiated_interaction_count, optional session_count)
• Field wired on CopilotDailyMetrics, CopilotUserDailyMetrics, and CopilotUserPeriodicMetrics
• Tests for daily and user-daily downloads; accessors regenerated via script/generate.sh

Fixes #4459

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 97.55%. Comparing base (27edd67) to head (ba5c8e5).

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #4460   +/-   ##
=======================================
  Coverage   97.55%   97.55%           
=======================================
  Files         194      194           
  Lines       19884    19884           
=======================================
  Hits        19398    19398           
  Misses        268      268           
  Partials      218      218           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[gmlewis]

Thank you, @Tens1des!
LGTM.
Awaiting second LGTM+Approval from any other contributor to this repo before merging.

cc: @stevehipwell - @alexandear - @Not-Dhananjay-Mishra

[stevehipwell]

I thought these were unmarshal only types so I'm unsure why they need omitempty?

[Tens1des]

Good question — omitempty only affects marshaling, so it's not required for Unmarshal itself.

I kept it to match the existing Copilot metrics types and the CONTRIBUTING guidance for response bodies (optional pointer fields use omitempty), and so nil fields round-trip cleanly via testJSONMarshal / user re-marshaling without emitting null.

Happy to drop it if you'd prefer these tags to be unmarshal-only.

[gmlewis]

I thought these were unmarshal only types so I'm unsure why they need omitempty?

Right - it is common practice in this repo to use pointers and omitempty for unmarshal-only types, especially when structs are used for many different endpoints. Then, when the GitHub v3 API servers do not provide fields, it is easy to see when they are not included.

I think it is fine to run with this without modification.

[stevehipwell]

@gmlewis I'm not sure I follow? The official docs for JSON struct tags say omitempty & omitzero are ignored during unmarshalling, and this type is unmarshal only. I also don't think the struct tag should be conflated with the use of a pointer.

[gmlewis]

@gmlewis I'm not sure I follow? The official docs for JSON struct tags say omitempty & omitzero are ignored during unmarshalling, and this type is unmarshal only. I also don't think the struct tag should be conflated with the use of a pointer.

Ah, I see exactly what you are saying, and you are right, @stevehipwell.

I think the biggest challenge in this repo is to determine which fields are unmarshal-only, so I wrote #4478 to analyze the situation.

I still like the point made by @Tens1des regarding:

and so nil fields round-trip cleanly via testJSONMarshal / user re-marshaling without emitting null.

So I think we should go ahead with this PR and merge as-is.

[gmlewis]

@alexandear or @Not-Dhananjay-Mishra - do you have any opinions in this matter?

[alexandear]

We can remove the omitempty in another PR.