Fix segfault on Windows when stdout is not a real console handle

[davesnx]

Summary

Fixes #124 — utop (and anything built on it, like Reason's rtop) segfaults on Windows in certain environments (e.g. GitHub Actions runners).

Problem

On some Windows environments, _isatty() returns true for handles that are not real console screen buffers. This likely happens due to ConPTY (Windows Pseudo Console). When lambda-term calls GetConsoleScreenBufferInfo on such a handle, it causes an access violation (segfault) instead of returning an error.

The crash path is:

1. LTerm.create → Lwt_unix.isatty returns true for stdout
2. Since outgoing_is_a_tty = true, get_size_from_fd is called
3. The C stub lt_term_get_size_from_fd calls GetConsoleScreenBufferInfo(Handle_val(fd), &info) with no handle validation
4. Access violation / segfault

Fix

1. C stub level (lTerm_term_stubs.c): Validate handles with GetConsoleMode before calling GetConsoleScreenBufferInfo / SetConsoleWindowInfo. Invalid handles now raise a Unix_error instead of crashing.

2. OCaml level (lTerm.ml): Wrap the get_size_from_fd call in LTerm.create with a try/catch. If getting the terminal size fails, fall back to treating the terminal as non-tty instead of crashing.

Testing

Tested by reproducing the issue on a GitHub Actions windows-latest runner with:

• OCaml 4.14.3
• lambda-term 3.3.3
• utop 2.16.0

Before fix: echo "1 + 1;;" | utop 2>&1 → Segmentation fault
After fix: should raise a catchable OCaml exception and fall back to non-tty mode