Render bridge: NO_COLOR must not strip the TUI's hues

The five "pre-existing" test failures (four corner-glow, one message-
paths muted-hash assertion) were all one thing: under a NO_COLOR
environment, Rich's console honoured it inside the TUI's headless
render bridge and stripped every named-style colour — but that console
is a rasterizer whose ANSI prompt_toolkit re-parses, not terminal
output, and the TUI's hues are semantics (node identity, recency
heat), not decoration. The bridge now pins no_color=False; the
scripted CLI's real console (theme.build_console) keeps honouring
NO_COLOR, where it belongs. Nothing was wrong with the tests or the
hash-widget commit they seemed to implicate.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

meshterm/ui/tui/render.py

@@ -42,6 +42,12 @@ def _console(width: int) -> Console:
             file=StringIO(),
             force_terminal=True,
             color_system="truecolor",
+            # This console is a rasterizer, not terminal output: its ANSI is re-parsed
+            # by prompt_toolkit, and the TUI's hues are semantics (node identity,
+            # recency heat), not decoration. So a NO_COLOR environment must not strip
+            # them here — the scripted CLI's real console (theme.build_console) is the
+            # one that honours NO_COLOR.
+            no_color=False,
             highlight=False,
             soft_wrap=False,
         )