ml_socket: include sys/select.h for fd_set

[coon42]

I am playing around with AI agents (specifically claude code) to automate away annoying and boring side tasks and to pay off some technical debt so this PR is AI assisted. Please let me know what you think about this kind of PRs and if this could be useful for ML. I've tried to keep change sets small and reviewable.

Motivation is to fix the build issue of #286. While trying to build ML on my Arch machine, I did run into some other issues which were fixed by the AI as well. Even though everything is part of the build fix, I have split them up into seperate PRs in case the AI made wrong assumptions.

Here is the AIs report:

ml_socket: include sys/select.h for fd_set

What

Add #include <sys/select.h> to src/ml_socket.h.

Why

socket_select_caller() is declared with fd_set and struct timeval
parameters, but ml_socket.h includes nothing at all. It worked only because
whatever included it had already pulled those in. newlib 4.5 provided them
transitively; newlib 4.6 and picolibc do not, so the only user of this header
fails to build:

../../src/ml_socket.h:33:48: error: unknown type name 'fd_set'

Both libcs define fd_set in <sys/select.h> (via sys/_select.h), which also
brings in struct timeval.

Relationship to #286

Same era, opposite direction. The lua breakage is one of our bundled headers
shadowing the toolchain's; this is one of our headers failing to include what
it uses. They need separate fixes and this one is not sufficient for that issue.

Risk

modules/yolo is the only file that includes ml_socket.h, so the blast radius
is one module.

Testing

Built platform/200D.101 with arm-none-eabi-gcc 15.2.1 from a clean tree: all
23 default modules and magiclantern.zip. Not tested on a physical camera.

Worth knowing: this failure hides behind stale objects. A yolo.o built before a
toolchain change will be reused and the build appears to pass — it only shows up
after make clean.

🤖 Generated with Claude Code

[reticulatedpines]

This doesn't repro here. The LLM analysis of the problem seems odd. It claims it's down to newlib version, but we include our own newlib, linked statically. If we're depending on system headers (entirely possible, that problem has been seen before in #286), then we want to stop doing so, not include more headers from system.