Node control endpoints stop publishing OTel spans for agent commands (GH-1670 follow-up)

[jeremydmiller]

What this does

Follow-up to the GH-907 system-traffic work, mirroring the 5.x change in #4117.

GH-907 stamps EndpointRole.System on any endpoint promoted to node control duty, which silences the meters — but the receive span and the pipeline-level execution span are gated by the endpoint's TelemetryEnabled flag, not the agent-command chain's (AgentCommandHandler already sets Chain.TelemetryEnabled = false, but that gate only covers the executor's own spans). So a broker control queue (EnableWolverineControlQueues on Rabbit MQ, Azure Service Bus, or SQS) or a TCP control endpoint (UseTcpForControlEndpoint) still published send, receive, and execution Open Telemetry spans for every IAgentCommand it carried — while the database control endpoint, born with TelemetryEnabled = false, was quiet.

The NodeControlEndpoint setter now switches TelemetryEnabled off alongside the System-role promotion, closing the hole for every promoted control transport at once. Node control traffic is nothing but agent commands and their replies.

Known trade-off

The three broker control queues also set IsUsedForReplies = true, and ReplyEndpoint() prefers such listeners — so on hosts that opt into broker control queues, replies to cross-node request/reply arriving on the control queue lose their receive span as well. Those queues are framework plumbing by design; their metrics were already silenced by the System role since GH-907.

Testing

• system_traffic_metrics_silencing.promoting_an_endpoint_to_node_control_duty_marks_it_as_system_and_disables_telemetry extended to pin the new flag (suite 13/13 green).
• Full CoreTests: 2642 passed, 0 failed on net9.0.
• Full wolverine.slnx builds clean pinned to net9.0 (Release).

🤖 Generated with Claude Code