`channels_sv2::server::share_accounting::ShareAccounting` needs refinement

[plebhash]

as proposed here #2107 (comment)

[gimballock]

Concrete suggestion for what this refinement needs:

1. Add rejected_shares: u32 field + increment_rejected_shares() to channels_sv2::server::ShareAccounting. Currently every Err(ShareValidationError::*) that produces a SubmitSharesError increments zero counters — the server is structurally blind to its own rejection rate at the library level.

2. Keep shares_accepted as the primary counter name on the server side (not acknowledged_shares). From the server's perspective it accepts shares; "acknowledgement" is the client's term for the same event seen from the other end of the wire.

3. With both counters in place, server-side monitoring can expose accepted_shares + rejected_shares per channel, enabling rejection rate alerting (rate(rejected) / rate(accepted + rejected)) without app-layer workarounds.

Note: not all ShareValidationError variants produce a SubmitSharesError — some are internal errors. The increment should only happen on the paths that actually send a SubmitSharesError downstream.

[gimballock]

submitted_shares vs validated_shares naming — the app layer renamed validated_shares (the channels_sv2 name) to submitted_shares. This collides with the existing shares_submitted field on ServerExtendedChannelInfo (which counts shares sent to upstream, a different concept). Recommend keeping validated_shares consistently across both layers to avoid confusion in dashboards and PromQL.

[gimballock]

snapshot_cache.rs needs updating — when the metrics rename lands, snapshot_cache.rs::update_metrics() references sv2_server_shares_accepted_total / sv2_client_shares_accepted_total and has stale-label-removal logic tied to those names. Will need updating alongside prometheus_metrics.rs.

[plebhash]

@gimballock unfortunately I'm not going to have the bandwidth to tackle this properly before we release v1.9.0 next week

I'm really sorry about that, I promise I'll do my best to jump into it ASAP!

moving out of v1.9.0 for now

[gimballock]

Based on a review of recent changes, much of the scope originally outlined in #2107 has now been delivered:

Already implemented:

• PR feat(channels): add blocks_found metric to ShareAccounting #2088: blocks_found metric added to ShareAccounting
• PR defer channels_sv2::client share acceptance to upstream acknowledgement #2090: Client share acceptance deferred to upstream acknowledgement (clear validation vs acceptance phase separation)
• PR fix channels_sv2::server::ShareAccounting::update_share_accounting  #2102: Fixed server::ShareAccounting::update_share_accounting batch acknowledgment logic
• PR channels-sv2: refine client share accounting counters #2114: Refined client share accounting counters (validated_shares/acknowledged_shares/rejected_shares)
• PR channels_sv2::client::share_accounting keeps track of error_code for rejected shares #2139 (just landed): rejected_shares changed from u32 to HashMap<String, u32> on client-side, keyed by error_code

Remaining concerns:

1. Server-side error_code breakdown — tracked in channels_sv2::client::share_accounting should keep track of SubmitShare.Error.error_code #2132
2. u64 work representation — tracked in PR fix(channels_sv2): migrate ShareAccounting from f64 to u64 #2116 / PR represent share work as u64 (where appropriate) #2138
3. Naming collision — @gimballock raised this in review: app layer renamed validated_shares to shares_submitted, which collides with the existing shares_submitted field on ServerExtendedChannelInfo (counts shares sent upstream, a different concept). Recommend keeping validated_shares consistent across both layers to avoid confusion in dashboards and PromQL.

Recommendation: Consider closing this issue and opening a focused follow-up just for the naming alignment if that remains a priority. The structural refinements from #2107's bullet points have largely landed.