Fix #10968: spawnProcess fails when RLIMIT_NOFILE exceeds int.max

[Poita]

Fix #10968

Summary

When RLIMIT_NOFILE is unlimited or exceeds int.max, spawnProcess fails with "Cannot allocate memory" due to integer overflow in the fd-closing code after fork().

Changes

• Use long instead of cast(int) for maxDescriptors to preserve the actual rlim_cur value
• Always try /dev/fd (or /proc/self/fd) enumeration first, regardless of the limit value — this is the most efficient path and avoids the malloc entirely
• Cap the brute-force fallback to 1M descriptors when the limit is huge
• Add unittest that sets RLIMIT_NOFILE above int.max and verifies process spawning works

Root cause

cast(int) of RLIM_INFINITY (2^63-1) wraps to -1, which:

1. Skips the /dev/fd enumeration path (since -1 < 128K)
2. Falls into the poll() path which tries to malloc a huge buffer and fails

Testing

• Standalone test confirms the bug reproduces with the system std.process and passes with the fix
• Added in-tree unittest for regression coverage

[dlang-bot]

Thanks for your pull request and interest in making D better, @Poita! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

• My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
• My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
• I have provided a detailed rationale explaining my changes
• New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

---

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + phobos#10969"

[0xEAB]

Where is that “magic constant number” coming from? How was it chosenß

[Poita]

Honestly, somewhat arbitrarily, but motivated by:

1. This path is only taken if maxDescriptors is >100k
2. If maxDescriptors is unlimited, closing all would take essentially forever.
3. In practice, it is very unlikely for a real system to have >1M FDs actually open, so this is effectively a "close everything"
4. Finally, basically no modern system would ever go down this path anyway since they'll all have /dev/fd -- only some very obscure systems would hit this.

So it's just a "sane limit" as the comment says, but could reasonably be something else. Just needed to choose something.