fix: WinResized forces redraw to clear stale pixels on tabline shift

The duplicate "turbo-debug" rows stacked at the top weren't from
orphan windows — they were leftover render pixels. When bufferline's
tabline disappears (buffer count drops back to 1), the tabline row
is reclaimed and every window shifts up one row. Nvim redraws at the
new positions but doesn't clear the pixels where the old render was,
so the content appears doubled.

OptionSet on showtabline doesn't fire in this case because
bufferline uses a %{% expr format for tabline — the tabline string
becomes empty but the showtabline option never changes. My earlier
BufEnter/TabEnter fallbacks miss it for the same reason. Only
WinResized reliably fires when windows shift from the reclaimed row.

New minimal WinResized autocmd: just schedules `redraw!` and does
nothing else. No re-pinning (user's manual resizes still stick), no
bar recreation (not needed for this case). Cheap and targeted.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

lua/turbo-debug/mode.lua

@@ -1143,6 +1143,21 @@ function M.enter()
     end)
   end
   vim.api.nvim_create_autocmd("VimResized", { group = group, callback = recover_chrome })
+  -- WinResized fires when any window's geometry changes — including
+  -- the shift that happens when bufferline's tabline disappears (the
+  -- tabline row gets reclaimed, all windows shift up). At that point
+  -- nvim re-renders at the new positions but doesn't always clear
+  -- the pixels where the old render was, producing the "duplicate
+  -- status bar rows" artifact. Forcing a full redraw here wipes the
+  -- stale pixels. We don't re-pin dapui sizes so user manual resizes
+  -- still stick.
+  vim.api.nvim_create_autocmd("WinResized", {
+    group = group,
+    callback = function()
+      if not active then return end
+      vim.schedule(function() pcall(vim.cmd, "redraw!") end)
+    end,
+  })
   vim.api.nvim_create_autocmd("OptionSet", {
     group = group,
     pattern = "showtabline",