test(multi): start the stuck bar before the render thread exists

The join_timeout test started its bar inside the multibar context, so a
render tick could catch the bar between _started=True and widget
population, crash the render thread on the empty-widgets assert, and
let join() succeed on a dead thread -- skipping the timeout path the
test exists to exercise (seen as a reproducible 99.93% coverage failure
on the py312 CI job). Start the bar fully up front; verified stable
across 10 consecutive runs and at 100% coverage on 3.12/3.14.

Author: wolph

tests/test_multibar.py

@@ -283,11 +283,17 @@ def test_multibar_join_timeout_abandons_unfinished_bar() -> None:
     multibar = progressbar.MultiBar(fd=io.StringIO(), join_timeout=0.1)
     bar = progressbar.ProgressBar(max_value=10)
     multibar['stuck'] = bar
+    # Fully start the bar before the render thread exists: started() flips
+    # true before the widgets are populated, so a render tick during a
+    # concurrent bar.start() can crash the render thread on the
+    # empty-widgets assert -- join() then succeeds on a dead thread and the
+    # timeout path this test exists to exercise is never taken.
+    bar.start()
+    bar.update(5)  # never reaches max_value / finish()
 
     def exit_context() -> None:
         with multibar:
-            bar.start()
-            bar.update(5)  # never reaches max_value / finish()
+            pass
 
     thread = threading.Thread(target=exit_context, daemon=True)
     thread.start()