fix(windows): use WinTab for pen contact while preserving mouse-mapped stylus buttons

[DustyShoe]

Summary

This PR improves Windows tablet behavior in the launcher for devices where the stylus side buttons are mapped by the driver to standard mouse buttons.

The key change is to stop relying on Chromium/Electron to interpret the entire tablet input stream on its own. Instead:

• stylus side buttons continue to use the normal mouse path
• pen contact and pressure are routed through a native WinTab bridge

This matches the intended behavior on the affected hardware: pen is only needed for contact + pressure, while buttons should behave exactly like mouse input.

Problem

On the affected Windows tablet setup, Chromium/Electron does not handle the split between tablet input and compatibility mouse input reliably under Windows Ink.

In practice this caused issues such as:

• hover pan started by stylus MMB getting stuck on release
• stylus RMB behaving inconsistently
• pen contact / pressure conflicting with Chromium's primary pen/mouse path

The root issue is not canvas logic itself, but limited tablet-input handling in Chromium/Electron for this kind of mixed input path.

Approach

This PR adds a Windows-only native WinTab bridge and uses it only for the primary pen contact path:

• add a native wintab-pen-bridge module
• use WinTab for pen contact and pressure
• keep driver-mapped stylus side buttons on the normal mouse path
• suppress the conflicting primary pen/mouse path before Chromium handles it
• forward synthetic pen contact events into the hosted Invoke UI through preload

Scope

This PR is intentionally limited to the Windows tablet-input fix in the launcher.

It does not include unrelated release/process/infrastructure changes.

Notes

• Windows-only behavior change
• non-Windows behavior should remain unchanged
• this path depends on a WinTab-capable driver