telemetry: populate hop_count on PutSuccess / UpdateSuccess / SubscribeSuccess events

[sanity]

Background

PR #4245 fixed the production telemetry bug where hop_count was None on ~99% of terminal GET events. Root cause was op_manager.get_current_hop(id) being called at log time, which returns None once the operation has been cleaned up.

The fix threaded hop_count through the wire (GetMsg::Response) so the originator has the populated value when constructing GET log events.

The remaining gap

PutSuccess, UpdateSuccess, SubscribeSuccess, and SubscribeNotFound events still carry hop_count: Option<usize> and ALL go through the same broken op_manager.get_current_hop() stub. They have the same None-on-99%-of-events bug.

Specifically:

• crates/core/src/tracing.rs:1271 — the PUT call site still uses the stub.
• crates/core/src/tracing.rs Subscribe paths — hop_count: None, // TODO: Track hop count from operation state (two sites).
• The op_state_manager::get_current_hop stub at crates/core/src/node/op_state_manager.rs:615 always returns None.

What needs doing

Same approach as #4245: add a positional hop_count field to:

• PutMsg::Response
• UpdateMsg::Response
• SubscribeMsg::Response

Thread the field through storer / relay / exhaustion paths, bump min-compatible-version for each, update tracing-side extraction with the same min(max_htl) clamp pattern, and add roundtrip + classifier-preservation unit tests.

Why not done in #4245

GET-only scope: GET is the operation the dashboard breakage was most visible for. Three additional wire-format-change PRs would have tripled review surface area.

[AI-assisted - Claude]

[github-actions]

🤖 Auto-labeled

Applied labels:

• T-bug (98% confidence)
• P-high (85% confidence)
• E-medium (80% confidence)
• A-networking (90% confidence)

Reasoning: This is a correctness bug in telemetry: hop_count is mostly None for several terminal events because code calls a stub (op_manager.get_current_hop) after cleanup. The fix requires wire-format changes (Put/Update/Subscribe responses), threading values through relay/storer/exhaustion paths, version bump, and tests. That is a bug (T-bug). It affects multiple operation types and production telemetry visibility, so it should be treated with relatively high priority (P-high). The required work spans moderate complexity (wire-format changes, protocol threading, tests), so E-medium is appropriate. The changes are primarily in networking/wire-protocol and tracing paths, so A-networking is relevant. Confidence is high based on the issue details describing exact files, stubs, and required changes.

Previous labels: none

If these labels are incorrect, please update them. This helps improve the auto-labeling system.