Record attachment operation counts in telemetry - #14360

Follow-up to #14327, which added attachment invocation counts.

Description

Attachment telemetry records how many --attach flags a command received, but not how successful uploads changed the command's Markdown.

This adds append_ops_count and replace_ops_count measures to the existing attachment_invocation event. An attachment that replaces several textual references counts as one replacement.

The event is registered before argument validation and resolved when telemetry flushes. It still reports attach_count for failed invocations, including authentication and validation failures, while successful uploads can add their operation counts to the same event.

How did you test this change?

I built the local gh binary and exercised a disposable test issue. I attached two PNGs, referenced the first twice in the comment body, and left the second unreferenced.

The posted comment rewrote both references to the first uploaded URL and appended the second attachment. With GH_TELEMETRY=log, I saw one attachment_invocation event with attach_count set to 2 and replace_ops_count and append_ops_count each set to 1, plus the paired command_invocation event.

I also ran the command with a missing attachment. It failed validation and logged attach_count as 1, with both operation counts set to 0.

The recordings project the raw log through jq so they show only event type, command, flags, and measures.

Mixed append and replace

Validation failure

Key points

• attachment_invocation uses dimensions {command} and measures {attach_count, append_ops_count, replace_ops_count}. It is sampled at 100%.
• After --attach is parsed, authentication, positional argument, and command validation failures retain attach_count and report zero operations.
• Partial failures count only uploads completed before the first failure. A final issue, pull request, or comment write failure does not erase completed Markdown operation counts.
• The event contains no paths, alt text, body content, repository information, or asset data.
• Generic command telemetry remains unaware of attachment behavior.

Notes for reviewers

Start with the telemetry recorder interface and service implementation. The important new pattern is RecordDeferred: a caller registers an event early, with its original recorded timestamp, but supplies a callback that resolves the final event during Flush. Sampling and disabled-telemetry checks still happen before the callback is evaluated. The existing immediate Record path is unchanged.

Then review InvocationTelemetry, which references the parsed attachment flag but owns the recorder and mutable event. Each command options struct stores it beside AttachFlag. It registers the deferred event from Cobra's argument validator, after flags are parsed but before positional argument validation. Successful uploads update this telemetry object before the process-level flush, producing exactly one attachment_invocation across subsequent validation and execution paths.

The telemetry service test covers flush-time resolution. The rooted attachment command test covers failure in a parent persistent pre-run hook, the lifecycle edge case that motivated the deferred recorder.

Authorship and follow-up

Who wrote this:

• A human wrote it.
• An agent wrote it under close human direction.
• An agent wrote it independently, and no human has guided the implementation beyond the initial prompt.

Who answers review comments:

• @BagToad will read and reply directly. Name the account.
• An agent will draft replies and @username will read them before they are posted.
• Nobody has explicitly committed to replying.