fix(work-panel): restore window dragging in unused tab-strip space

[AR307]

Summary

Unused space in the work-panel header cannot drag the native window because
the flexible tab-strip wrapper is marked no-drag. Keep the header as the single
drag owner and limit no-drag to individual tabs and existing action controls.

Reproduction

On the original reproduction base def015ebb, open the work panel with
one or two tabs and try dragging the unused strip space to their right. Although the header is styled
as a native drag region, the wrapper covers that area with no-drag.

In an isolated Windows Electron window mounting the production WorkPanel and
styles, WM_NCHITTEST returns HTCLIENT (1) for that empty area. With this change
it returns HTCAPTION (2); the interactive tab and action targets remain HTCLIENT.

Changes

• Remove no-drag from the flexible wrapper.
• Apply no-drag to each interactive tab.
• Extend the existing production-component reorder probe to protect this
  ownership rule; retain all existing interaction checks.
• Clarify the UI contract and the existing work-panel acceptance scenario.

No changes to window-control reservations, pointer-reorder logic, IPC, storage,
MC/provider integration, or dependencies.

Validation

• 70 work-panel source/geometry/reorder test cases passed on refreshed upstream.
• Production WorkPanel in isolated Electron: select/close/add/maximize action
  callbacks and the existing reorder/cancellation probe passed.
• Windows native hit-testing verified empty space becomes HTCAPTION and
  tab/close/add/maximize hit targets remain HTCLIENT.
• The earlier style-token check passed.
• Full pnpm build:js, desktop typecheck and current sidecar bundle passed.
• Rust host-core release build (Cargo 1.90.0) passed; the complete isolated
  desktop booted with a successful host handshake and sidecar readiness.
• PR base ancestry and git diff --check passed.

Environment: Windows, Electron 43.6.0, Chromium 150.0.7871.250.

Physical mouse acceptance: the tester manually dragged the rebuilt isolated
Windows desktop from unused work-panel header space and confirmed on
2026-10-05 that the window moves. This is a manual result, not a claim that
the automated native-caption drag gesture passed. macOS/Linux native checks
and packaged installers were not run.

Tested candidate: e697cea.
Upstream base: 10e824e.

Scope review

The change fixes the existing drag-owner contract and is independent of the
browser capture fix. PR #455 addressed related chrome ownership but the current
flexible strip still blocks the empty area. No exact open duplicate was found
in the refreshed 2026-10-05 check.

[vastsa]

Thanks for the precise reproduction and the Windows native hit-test evidence. This fixes drag ownership at its source while keeping tabs and actions interactive; the regression probe and CI are green. Merged as c376e4a. I appreciate the careful validation.