Delete the tab-bar hit-region shim (570 lines) and adopt TabBarLayout/TabGroupController — the migration it waited for never happened

[JDonaghy]

Problem

src/render.rs:456-1025 (570 lines) is compute_tab_bar_hit_regions, plus tab_bar_hit_bands at :20309 (89 lines). Its own doc at :574-580 states its lifespan:

"Until TUI / GTK / Win-GUI migrate to consume TabBarLayout directly, this shim is the bridge."

Win-GUI was deleted on 2026-05-11 (3e4bcff). The migration never happened. The shim is now permanent scaffolding for a condition that can no longer be met.

Separately, quadraui ships compose/tab_group.rs — TabGroupController (3,130 lines: drag, drop zones, split). vimcode references it once, and that reference is a stale doc comment at src/render.rs:9427 claiming drag is "Handled by TabGroupController" while the code actually uses vimcode's own render::TabDragState.

vimcode's parallel implementation:

• src/render.rs:4873-5012 — TabDragState (~140 lines)
• src/render.rs:21121-21442 — tab drop-zone (~322 lines)

History: #515 deferred full TabGroupController adoption "see quadraui#395". quadraui#395 closed the same day and no follow-up issue was ever filed — this issue is that follow-up.

Fix

1. Migrate both backends to consume TabBarLayout directly; delete compute_tab_bar_hit_regions and tab_bar_hit_bands (~659 lines).
2. Adopt TabGroupController for tab drag and drop zones; delete TabDragState and the local drop-zone code (~460 lines).
3. Fix or delete the false doc comment at src/render.rs:9427.

Ordering: the GTK tab-bar click issue earlier in this chain touches src/gtk/click.rs:434-608. Land that first; this issue assumes it has.

Acceptance

• Black-box tests required, both backends: tab click, tab close button, tab drag-to-reorder, drag-to-split drop zones.
• Per feedback_cache_paint_layout, hit-testing must read what paint produced — never re-derive layout in the click handler.
• State in the PR that the new tests fail against unfixed develop.

[JDonaghy]

Depends on #814, which removes GTK's re-implementation of Engine::handle_tab_bar_click from src/gtk/click.rs:434-608. This issue assumes that has landed; starting first will conflict in the same file.

[JDonaghy]

Before you start: re-verify the citations, do not trust them

Every file:line in this issue was measured on develop @ ee26268 (2026-09-04) by an audit, not by reading the tree you will check out.

They will have drifted by the time you pick this up. This issue sits in a serialised chain, and several entries ahead of it move code on purpose — #812 deletes ~1,300 lines from src/render.rs, #813 retypes fields in src/app.rs, #785 and #814 delete whole functions. Anything filed after those shifts.

So:

• Locate by symbol, not by line. grep -n "fn build_screen_layout_with_breadcrumb_row" src/render.rs, not "go to line 12886". GOALS.md already carries this rule for the same reason — it cites no line numbers on purpose.
• Re-measure any count before you use it. Line totals here came from python3 scripts/prod_lines.py and scripts/native_lines.py at a named revision. Re-run them rather than quoting the number in this issue. GOALS.md: "regenerate them with the script rather than trusting the table."
• Size the branch from what you find, not from the figure here. The counts are evidence that a problem is large, not estimates of a diff.

If a finding does not reproduce, say so — that is a useful result

This issue was generated from an automated audit. Some of its claims are wrong. Today alone, two confident findings in the same audit chain did not survive checking: a "1,671 byte-identical lines" figure measured out at ~85, and a "zero commits of pin lag" reading was taken against a stale local ref and was actually 42.

If the problem described here is already fixed, was never real, or is real but different from the description: comment with what you actually found and stop. Do not implement around a bad premise to make the issue closeable. A correction is worth more than a merged PR built on a wrong claim.