Implement sync bandwidth metrics (bytes_sent/bytes_received)

[kitplummer]

Summary

GetSyncStats returns hardcoded zeros for bytes_sent and bytes_received, providing no visibility into mesh bandwidth consumption.

Current State

In src/node.rs:221-228:

pub fn sync_stats(&self) -> SyncStats {
    SyncStats {
        sync_active: self.is_sync_active(),
        connected_peers: self.connected_peer_count(),
        bytes_sent: 0,       // always 0
        bytes_received: 0,   // always 0
    }
}

The proto definition (proto/sidecar.proto:340-345) already defines bytes_sent and bytes_received as uint64 fields in GetSyncStatsResponse, but they're never populated.

Proposed Approach

1. Instrument the transport layer: Add byte counters to MeshSyncTransport or wrap the Iroh QUIC connections with metered I/O
2. Per-peer granularity: Track bytes per peer connection, aggregate for the total stats response
3. Atomic counters: Use AtomicU64 on SidecarNode (or in MeshSyncTransport) that get incremented on each sync operation
4. Extend proto (optional): Add per-peer byte stats to PeerInfo message for more granular monitoring

Where to hook in

• sync_on_change() (src/node.rs:131-148) — outbound sync calls coordinator.sync_document_with_all_peers(). The coordinator or transport could report bytes after each sync.
• SyncProtocolHandler — inbound sync could report received bytes via a callback or shared counter.
• If peat-mesh doesn't expose byte counts, this may require changes upstream in the peat-mesh crate.

Impact

Operational visibility is critical for DDIL environments where bandwidth is constrained. Operators need to understand how much data is flowing through the mesh to tune poll intervals, manage link budgets, and diagnose sync issues.

Files

• src/node.rs:221-228 — sync_stats() stub
• src/node.rs:131-148 — sync_on_change() outbound path
• proto/sidecar.proto:340-345 — GetSyncStatsResponse message