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).

[github-actions]

Hey! Your PR title tui: fix Shift+Enter newline on Windows doesn't follow conventional commit format.

Please update it to start with one of:

• feat: or feat(scope): new feature
• fix: or fix(scope): bug fix
• docs: or docs(scope): documentation changes
• chore: or chore(scope): maintenance tasks
• refactor: or refactor(scope): code refactoring
• test: or test(scope): adding or updating tests

Where scope is the package name (e.g., app, desktop, opencode).

See CONTRIBUTING.md for details.

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

Potential Duplicate Found

PR #3965: Differentiate Shift+Enter from Enter for prompt submission
#3965

This PR appears to address the same issue - differentiating between Shift+Enter (newline) and Enter (submit) in the prompt/textarea. This is directly related to the current PR #8040, which fixes the Windows-specific case where this differentiation was broken.

[rekram1-node]

@kommander possibly something opentuis houdl handle?

[kommander]

Interesting workaround. @Hona you think that makes sense? Could bring that in opentui.

[Hona]

I reached out on discord to kmdr, this is an API I've used in high render throughput C# console apps.
Good option.