Logger subsystem refactoring for concurrent multi-mode output

[HeatCrab]

The logger subsystem needs architectural improvement to reliably handle concurrent output from M-mode and U-mode tasks.

These issues were identified during U-mode(#62) and PMP(#32) development:

• Output Interleaving due to Unprotected I/O Loops #64
• DoS vulnerability in sys_tputs through unbounded NOSCHED blocking #65
• Non-monotonic output timeline in mixed M-mode/U-mode execution #66

These issues are not independent bugs—they stem from a fundamental design tension: async logging via ring buffer and direct UART output via sys_tputs coexist without synchronization. Patching any single issue in isolation is likely to require changes that affect the others.

A proper fix will involve rethinking how output paths interact, which means the logger architecture needs refactoring. This issue tracks the overall effort.

Acceptance Criteria

• All three issues (Output Interleaving due to Unprotected I/O Loops #64, DoS vulnerability in sys_tputs through unbounded NOSCHED blocking #65, Non-monotonic output timeline in mixed M-mode/U-mode execution #66) are resolved
• A dedicated test application validates concurrent output behavior
• No output interleaving when multiple tasks print simultaneously
• Output from M-mode and U-mode tasks appears in execution order

[HeatCrab]

While continuing to survey the issue, I thought of a key consideration: in the refactor work, what is the role of U-mode I/O? This is quite important as it affects the direction of the refactoring.

In linmo, the current logger queue (8 entries, 128 bytes each) was sized for kernel-only workloads. If we route U-mode traffic through it, the contention where a user task flooding output could cause kernel messages to hit the drop/fallback path should be considered. Or is it better to keep the two paths separate but add proper synchronization at the output layer, so they don't interleave at the UART level?

The latter sounds like it makes more sense to me, but I'm not quite sure.