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"

[Poita]

Friendly bump on this one. Would be really nice to be able to use dub with ghostty on Mac without having to workaround. It's a very bad initial experience for anyone trying D on Mac that happens to use ghostty.