feat(panes): Tab per Ziehen als Pane in den sichtbaren Tab einfügen

[iret77]

Baut auf feat/unified-launch-menu-tab-to-pane auf; bitte nach diesem PR mergen.

Was

Ein Tab lässt sich mit der Maus als Pane in den sichtbaren Tab ziehen. Vorbild sind VS Code und JetBrains: Man zieht einen Tab in den Editorbereich, und eine Drop-Fläche zeigt die Zielposition.

• Den Tab aus der Tab-Leiste oder dem vertikalen Tab-Panel in den Inhaltsbereich ziehen. Über einem Pane des sichtbaren Tabs markiert eine Fläche im Theme-Akzent die Hälfte (links, rechts, oben, unten), an der er eingefügt wird. Die Richtungslogik ist dieselbe wie beim Ziehen an der Pane-Kopfzeile (calculate_pane_move_direction).
• Beim Loslassen wandern alle sichtbaren Panes des gezogenen Tabs samt Anordnung als Split dorthin. Sessions, PTYs und Agenten laufen weiter, der leere Quelltab schließt sich, und der Fokus liegt auf dem vorher fokussierten Pane des gezogenen Tabs.
• Innerhalb der Tab-Leiste bzw. des Panels wird wie bisher umsortiert. Loslassen ohne Drop-Fläche ändert höchstens die Reihenfolge.
• Die Gegenrichtung gibt es schon: Pane-Kopfzeile auf die Tab-Leiste ziehen.

Umsetzung

• tab.rs: Die horizontalen Tabs aktivieren bei on_click statt on_mouse_down, wie die vertikalen Tabs. Ohne DragTabsToWindows ist der Tab-Drag nicht mehr auf die horizontale Achse gesperrt, sondern auf das Fenster begrenzt.
• vertical_tabs.rs: Ebenso wird die senkrechte Sperre durch die Fenstergrenze ersetzt. Gezogen wird dort der ganze Tab mit allen Panes, auch wenn das Panel jedes Pane als eigene Zeile zeigt.
• tree.rs: PaneLayout beschreibt die sichtbaren Panes; dazu kommt has_hidden_panes_in_use.
• pane_group: take_panes_for_join und insert_joined_panes. Die Anordnung entsteht neu aus Splits: erst die Geschwister nebeneinander, dann jedes Kind. Reihenfolge und Verschachtelung bleiben erhalten, die Größen starten gleich verteilt. Dateimanager-Overlays wandern über PaneMoveBundle mit. Ein Pane, das nicht neben seinem Nachbarn platziert werden kann, landet am Tabrand und geht nicht verloren.
• workspace: tab_join_drop_target_at, join_tab_as_pane und das Overlay. Gesperrt sind Tabs mit verborgenen laufenden Panes (Hintergrundjob, Child-Agent, laufender Move) und Tabs mit laufendem provisorischem Daemon- oder Managed-Start, wie beim Fenster-Drag.

Bekannter Kompromiss

Ein Drücken, bei dem sich die Maus mehr als 5 px bewegt, gilt als Drag (Schwelle des Draggable) und aktiviert den Tab beim Loslassen nicht. Bei den vertikalen Tabs ist das schon heute so. Das ist also konsistent und keine Regression.

Verifikation

• Statisch: rustfmt --check, git diff --check, check-no-new-cjk, check-persistent-hover-state, check-v1-release-readiness --phase-a.
• Nicht kompiliert: Kompilierung und Tests laufen im ci-batch erst nach Freigabe.
• Tests: visible_layout_mirrors_nesting_and_skips_hidden_panes, only_running_or_moving_hidden_panes_block_handing_over_a_group und dragging_a_tab_onto_a_pane_joins_its_panes_as_a_split (gleiche PaneIds in Originalreihenfolge, Fokus übernommen, Quelltab geschlossen, sichtbarer Tab ist nie sein eigenes Ziel).
• Die native Abnahme (Maus-Drag, Overlay in Hell/Dunkel) braucht einen DMG-Build.

Nicht enthalten

• Ursprüngliche Größenverhältnisse eingefügter Panes bleiben nicht erhalten.
• Tab-Abriss in neue Fenster: DragTabsToWindows bleibt aus.