fix: decouple different ipc data channels

[Nemo157]

In some situations the ipc channels from actors to the background task can get overloaded. Currently we don't have a complete plan for how to handle this. But the major source of messages is telemetry, which is also one we can treat less reliably, so by dividing this from the data messages we can deprioritize them.

Relates to #149

[github-actions]

Deployment - Branch link	Commit link - 5e7c8b8
user-manual preview	https://a71a0e26.user-manual-2bd.pages.dev
private-docs preview	https://3c49807d.private-docs-3bh.pages.dev
veecle-telemetry-ui preview	https://d084cc15.veecle-telemetry-ui.pages.dev

[codecov]

Codecov Report

❌ Patch coverage is 5.40541% with 35 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
veecle-ipc/src/connector.rs	0.00%	30 Missing ⚠️
veecle-ipc/src/actors/output.rs	0.00%	5 Missing ⚠️

📢 Thoughts on this report? Let us know!

[claude]

Change Summary

This PR decouples IPC data channels by separating storable messages, telemetry messages, and control requests into distinct channels. The implementation introduces OutputTx and OutputRx structs that manage three separate MPSC channels with independent buffering. A prioritized recv() method uses tokio::select! with biased polling to drain control requests first, then storable messages, then telemetry. This allows telemetry (which can be chatty) to be dropped when overloaded without affecting critical storable or control messages.

Issues Found

🔴 Critical

Duplicate dependency in Cargo.toml
The veecle-telemetry dependency appears twice in dev-dependencies (lines 28 and 31 of Cargo.toml), both with identical feature sets. The second entry at line 31 should be removed as it's redundant.

🟡 Important

Comment inaccuracy regarding buffer size
Line 59 in connector.rs:59 states "Telemetry can be quite chatty, so give it a large buffer" but then creates a channel with capacity 128, which is identical to the storable channel. Either the buffer size should be increased to match the comment, or the comment should be corrected to reflect that all data channels have equal capacity.

Missing rationale for channel priorities
The prioritization order (control > storable > telemetry) in OutputRx::recv() is critical to system behavior but lacks explanation. The comment at line 37-38 mentions potential starvation of low-priority channels but doesn't explain why this specific ordering was chosen or what the operational implications are.

[vE5li]

Makes sense 👍

[alexveecle]

In general this looks good to me; however... does this need a changelog entry or some addition to the docs? Is this part of a broader initiative? I see no issue associated?

Also, wasn't there issues with telemetry becoming lost if some message was lost? Does this mean that telemetry might be more unreliable? (I think this is completely fine- but perhaps we should warn somewhere that telemetry is "best effort" or something.)

[Nemo157]

Yes, if telemetry messages are lost that can cause issues with rendering them (currently the ui itself panics, it could be more resilient for some kinds of missing messages, but there is context-dependence that mean it still may not make sense afterwards).

I do think we need more improvements, this is just a way to try to avoid some situations that can cause panics currently.

Added an issue link.