Decouple Rerun debug logging from real-time auto-aim pipeline

[XiaoPengYouCode]

Background

The current visualization path can call Rerun logging directly from runtime code. For development this is convenient, but in a high-frequency auto-aim pipeline it risks adding serialization, allocation, file/gRPC IO, queue pressure, and timing jitter to the critical path.

Goal

Define a lightweight debug event spec for the auto-aim pipeline, then move Rerun-specific rendering into a separate debug worker. The real-time vision / solver / estimator path should only enqueue compact debug events and must never block on Rerun, gRPC, or file IO.

Proposed design

• Define a project-owned debug event enum / spec, for example:
  • frame metadata
  • detected armor corners / confidence / label
  • solved armor pose
  • enemy state estimate
  • control output yaw / pitch / fire
• High-frequency pipeline code only calls a non-blocking enqueue API, e.g. try_push(DebugEvent).
• Use a bounded queue; when full, drop debug events instead of blocking the pipeline.
• Run a separate debug worker thread/task that drains events and translates them to Rerun archetypes.
• Gate the whole debug path behind config so competition / release runtime can disable it or lower its rate.

Non-goals

• Do not put Rerun API calls directly in the real-time pipeline.
• Do not make debug logging part of correctness or control output.
• Do not introduce blocking sends, awaits, file IO, or gRPC calls on the hot path.

Acceptance criteria

• A clear DebugEvent spec exists in the project code.
• Hot-path code can emit debug events through a non-blocking bounded queue API.
• Rerun rendering is isolated in one worker/module.
• Queue overflow drops debug data safely and observably.
• Debug output can be disabled from config.
• cargo check --workspace and tests pass.

Notes

This can start as an in-process worker. A separate process is only needed later if we want stronger isolation from Rerun crashes or heavier visualization workloads.