fix(tui): fix Shift+Enter newline on Windows

[Ashwin-droid]

What does this PR do?

Video Fixes #8038

Summary

Fixes Windows prompt behavior where Shift+Enter was treated like Enter (submitting) instead of inserting a newline, restoring the intended “newline vs submit” UX.

Details

• Observed behavior (Windows Terminal/ConPTY): Shift+Enter can be delivered as an unmodified return key event, so it matches the textarea’s return → submit binding (same path as plain Enter).
• Implementation: Add a Windows-only modifier fallback in packages/opencode/src/cli/cmd/tui/context/keybind.tsx:
  • Load user32.dll via bun:ffi and call GetAsyncKeyState(VK_SHIFT) (VK_SHIFT = 0x10).
  • When receiving an event with:
    • evt.name === "return"
    • evt.shift/ctrl/meta/super/hyper all false
    • GetAsyncKeyState indicates Shift is currently down (state & 0x8000)
    • then set evt.shift = true before matching keybinds.
• Scope control (narrow by design): Only applies to return events with no other modifiers and only on process.platform === "win32", so the change is intentionally limited to the broken case.

How did you verify your code works?

• The attached screen capture makes the corrected behavior evident end-to-end on Windows (newline insertion with Shift+Enter, submit with Enter).
• Ran bun run typecheck (repo typecheck via the pre-push hook / turbo typecheck).