fix(dockview-core): add drop target for tab group chip

[mathuo]

Summary

When a tab group is the first item in a tabs container, the chip sits before the group's first tab in the DOM and covers the position-0 drop slot. The chip had no Droptarget and the tabs container's dragover handler bails for individual tab drags in default animation mode (tabs.ts:318-324), so hovering over the chip was a dead zone — no overlay, no drop.

• Attach a Droptarget to chip.element in TabGroupManager._ensureChipForGroup, accepting only the leading zone (left horizontal / top vertical) at 100% activation, so the whole chip = "before this group".
• canDisplayOverlay mirrors Tab's pattern: respects locked/disableDnd, suppresses the overlay in smooth mode (the gap-shift animation already covers that case), delegates to group.model.canDisplayOverlay for cross-accessor drags.
• New onChipDrop callback wired from TabGroupManager → Tabs._handleChipDrop, which resolves the insertion index to the group's first tab and applies the standard same-group source-removal adjustment.
• updateDirection() on TabGroupManager refreshes target zones when the header direction changes.

Test plan

• yarn jest --selectProjects dockview-core (920 passed, +2 new regression tests)
• Manual: default animation mode — drag a tab over the chip of the first-positioned group → overlay appears on chip's leading edge, drop inserts the tab before the group.
• Manual: smooth animation mode — drag a tab over the chip → existing gap-shift animation still works (chip's Droptarget overlay is suppressed).
• Manual: vertical header direction — same as above with the top zone.
• Manual: locked group — chip does not accept drops.

🤖 Generated with Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
2 New issues
0 Accepted issues

Measures
0 Security Hotspots
75.7% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud