fix(collector): C# log quality — quiet graceful-stop discard, HTTP code in single-command failure

[lotgon]

What

The native collector log-quality fixes (#1225) surfaced two issues that also exist in the C# collector (native is a port of it). This mirrors them:

1. Graceful-stop discard is not an Error. DataProcessor.LogDiscardedItems logged "{queue} queue discarded N item(s) during collector shutdown." at Error on every graceful stop. Dropping still-buffered values on a bounded shutdown is expected and contracted (a stop must not block on a dead/slow transport) — now Info.
2. HTTP status in the single-command failure log. The batch registration-failure path already logs Status Code: {response.StatusCode}; the single-command path (CommandHandler.HandleRequestResultAsync(response, value, …)) logged only the body text. Add the status code for consistency (parity with the batch path and with the native fix(collector): log quality — relabel runtime registrations, HTTP code, quiet stop-drop #1225 fix).

Not changed (intentionally)

• Registration resilience (native Added HSMCppWrapper project #5): C# is already more resilient — registration commands sit in a persistent command queue and retry unboundedly on connection failures, recovering without a restart. The native collector was one-shot; its companion PR brings native up to this. No C# change needed.
• Per-registration "accepted" Info verbosity (native Change the protocol in the project to GRPC #1): milder in C# (no false "on connect" label), and cleanly fixing it needs a connect-vs-runtime distinction to avoid losing the Info registration signal — deferred.

Verified locally

• HSMDataCollector builds clean on net6.0 (0 errors).
• Shutdown + command unit tests: 27 passed, 0 failed (net48).

Logging-only; no behavior change. The C# collector is a published package, so a version bump is left as a release decision (root AGENTS.md: bump only when preparing a release).

🤖 Generated with Claude Code

[github-actions]

Code Review — PR #1226: C# collector log quality

Verdict: ✅ Approve. Two small, well-scoped, logging-only changes. I verified both against the surrounding code and found no bugs, security, or performance concerns.

What was checked

1. DataProcessor.LogDiscardedItems — Error → Info

• The method has a single caller (FlushAndLogAsync, line 217), which runs ClearQueue() only after a bounded FlushAsync attempt during StopAsync. So the log genuinely fires on the graceful-shutdown path only — downgrading it to Info will not hide a runtime fault. ✔️
• Overflow/eviction drops during normal operation go through a separate path (EmitOverflowDrops → QueueOverflowSensor), so operational data loss is still surfaced independently. The severity downgrade here does not silence that signal. ✔️
• The added comment accurately explains the rationale.

2. CommandHandler.HandleRequestResultAsync — add Status Code

• The new message format is character-for-character consistent with the existing batch failure log in the same file (line 66: "...has been faulted. Status Code: {response.StatusCode}, Status Text: {error}."), so parity is genuine, not approximate. ✔️
• The change is inside the if (!isSuccess) branch, where response is already known non-null (line 84 guards response == null), so response.StatusCode cannot NPE. ✔️

Minor / optional (non-blocking)

• error can be null. JsonSerializer.DeserializeAsync<string> (line 93) returns null if the response body is literally null or empty. The interpolated log would then render Status Text: . — cosmetically odd but harmless. This pre-existed on the batch path too, so it's outside this PR's scope; flagging only for awareness.
• The label Status Text: holds a deserialized error body, not the HTTP reason phrase — slightly imprecise wording, but it matches the existing batch log, so keeping it consistent is the right call.

Notes

• No behavioral change; risk is limited to log severity/verbosity, as the PR description states.
• Build (net6.0) and the 27 shutdown/command tests (net48) reportedly pass; the diff is small enough that I have no reason to doubt this.

Nice, tightly-scoped fix with an accurate PR description and a helpful inline comment. 👍