Fix HighNumberedFd_NotLeakedAfterLoweringRLimit on 32-bit musl - #135867

…bit musl (#137407)

Backport of #135867 to release/11.0. The main fix was contributed by
@pcshrosbree.

/cc @krwq @pcshrosbree

## Customer Impact

- [ ] Customer reported
- [x] Found internally

The ProcessHandles descriptor-leak test fails during setup on Alpine
ARM32, adding an unrelated failure to validation of .NET 11 servicing
changes. The test declares `rlim_t` fields as `nuint`, but musl uses
64-bit fields even on 32-bit platforms. This makes its libc
`getrlimit`/`setrlimit` declarations incorrect.

This backport addresses #136327 by using the existing `System.Native`
resource-limit interop, which converts to and from the platform's native
structure. It retains the descriptor-leak check rather than disabling
ARM32 coverage. Only the test and its project file change; there is no
shipped runtime behavior, public API, package or reference-assembly
change.

## Regression

- [x] Yes
- [ ] No

Test-only regression introduced by #135753, which added
`HighNumberedFd_NotLeakedAfterLoweringRLimit`. The test's assumption
that `rlim_t` is pointer-sized does not hold on musl ARM32. This is not
a regression in shipped runtime behavior.

## Testing

The existing regression test is corrected; no test is disabled or
removed.

Validation reported on the merged main PR #135867:

- Linux x64: 44 ProcessHandles tests passed; the full Process test
project reported 675 passed, 6 skipped and 0 failed.
- Reintroducing the descriptor-leak bug caused the corrected test to
fail, confirming that it still detects the intended product regression.
- Alpine ARM32 emulation reproduced the native layout mismatch and
verified the resource-limit calls through `System.Native`. This was a
focused console repro, not the full Process test on Alpine ARM32
hardware.

Backport validation:

- [CI build
1677098](https://dev.azure.com/dnceng-public/public/_build/results?buildId=1677098):
the `Build linux_musl-arm Debug AllSubsets_CoreCLR_ReleaseRuntimeLibs`
job passed, but the overall runtime pipeline failed. Build Analysis is
also red; these failures have not been classified in this description
update.
- [Linker-test build
1677100](https://dev.azure.com/dnceng-public/public/_build/results?buildId=1677100)
passed.
- A passing result for the corrected test on Alpine ARM32 has not yet
been confirmed for this backport. The passing build job alone does not
establish that the test passed.
- No local build or tests were run for this backport in this session.

## Risk

Low. The diff is limited to `ProcessHandlesTests.Unix.cs` and
`System.Diagnostics.Process.Tests.csproj`. It replaces test-local libc
resource-limit declarations with existing shared interop and preserves
the test's leak assertion and the returned hard limit. No shipped
product code or dependencies change.

The main PR's validation provides evidence that the test still catches
descriptor leaks, but the backport's failing CI and Alpine ARM32 test
result still need resolution before treating validation as complete.

**IMPORTANT**: If this backport is for a servicing release, please
verify that:

- For .NET 8 and .NET 9: The PR target branch is `release/X.0-staging`,
not `release/X.0`.
- For .NET 10+: The PR target branch is `release/X.0` (no `-staging`
suffix).

This PR targets `release/11.0`.

## Package authoring no longer needed in .NET 9

**IMPORTANT**: Starting with .NET 9, you no longer need to edit a NuGet
package's csproj to enable building and bump the version.
Keep in mind that we still need package authoring in .NET 8 and older
versions.

Fixes #136327

> [!NOTE]
> This PR description was prepared with GitHub Copilot.

Co-authored-by: Peter Shrosbree <[email protected]>