fix(ui): end the text selection before a click stops propagation

[Tryanks]

Summary

A click handler that swallowed its MouseUp left gpui-base's window selection in its drag state: the Markdown body followed the pointer until the next release, and the release after that was needed to clear it. Reported on the async question strip's ✕ and earlier on the notification close button.

 MouseDown (bubble)  gpui-base: is_selecting = true
 MouseMove (bubble)  gpui-base: cursor follows pointer
 MouseUp   (bubble)
   button.on_click
+    TextSelection::end          ← widgets::stop_click_propagation
     cx.stop_propagation()
-  root TextSelectionLayer: end()   ← never reached

One owner, widgets::stop_click_propagation(window, cx), replaces every bare cx.stop_propagation() inside an on_click (14 sites) and the four Markdown link handlers that already did the pair by hand. on_mouse_down sites are untouched: they block the gesture from starting, and the release still resets the state.

Evidence

• Before: the new test, with the fixture's button calling only cx.stop_propagation():

  FAIL markdown::view::tests::click_that_stops_propagation_does_not_leave_selection_following_pointer
  panicked: the released pointer kept selecting text
  

  After: same test through the helper, plus the rest of the crate:

  cargo clippy -p tcode-ui --all-targets -- -D warnings   clean
  cargo nextest run -p tcode-ui                           290 passed, 0 failed
  

Merge Danger

Door: two-way

Pure tcode-ui change behind one helper; reverting the commit restores the old behaviour.

Blast Radius: clicks

Every click that stops propagation now also ends an in-progress selection gesture. TextSelection::end keeps the selection visible, so a click on a button while text is selected still leaves the selection as before.

Test met on the way

tcode-traverse host::tests::a_self_hosted_machine_starts_without_its_manifest_and_applies_it_when_it_arrives failed on Linux in this PR's first CI run and passes on main's last six. Step 1 (driver): the test reset the manifest loader's pacing stamp while the host's own spawn_refresh loop was about to run its first pass; when the runtime scheduled that pass after the reset, it fetched the manifest itself and the test's direct refresh() returned None. The test now aborts the host's loop before taking over the refresh. The contract (a manifest arriving after startup is applied) was already driven through apply_manifest directly and never depended on the loop. 30 consecutive local runs pass.