Rhel 6: ZGC uncommit capability is disabled

**Summary**

OpenJDK unit test gc/z/TestUncommit.java fails (timeout) when run on a rhel 6 machine, likely because [JEP 351](https://openjdk.org/jeps/351) disables gc uncommit on older Linux kernels.

**Investigation**

- Looks like the test [runs the gc](https://docs.oracle.com/javase/8/docs/api/java/lang/System.html#gc--) ( using the z gc policy) and waits until the amount of [total memory](https://docs.oracle.com/javase/8/docs/api/java/lang/Runtime.html#totalMemory--) (not free, total) increases relative to the total at the start of the test. Seems this results in it waiting forever, rather than failing and producing a more useful error message.
- Two stack traces say the hang occurs at TestUncommit.java:85
- The test code for this can be found [here](https://github.com/openjdk/jdk17u/blob/162dbac82cf31c6948414944af836187aff9e6ca/test/hotspot/jtreg/gc/z/TestUncommit.java#L85).
- This code has not been changed in 5 years, so I'm more likely to suspect the z gc policy itself, or a machine issue.
- Both failures occurred on [test-ibmcloud-rhel6-x64-1](https://ci.adoptium.net/computer/test-ibmcloud-rhel6-x64-1), however the latest pass happened on [test-ibmcloud-ubuntu1604-x64-1](https://ci.adoptium.net/computer/test-ibmcloud-ubuntu1604-x64-1).
- Found this in the debug output, which explains the problem:

03:09:26 [0.019s][error][gc ] Failed to uncommit memory (Not supported)
03:09:26 [0.019s][info ][gc,init] Uncommit: Implicitly Disabled (Not supported by operating system)

- Useful code [here](https://github.com/openjdk/jdk17u/blob/162dbac82cf31c6948414944af836187aff9e6ca/src/hotspot/share/gc/z/zPhysicalMemory.cpp#L269).
- Rerunning on a rhel 7 machine: https://ci.adoptium.net/job/Grinder/13622/
- Jie identifies [JEP 351](https://adoptium.slack.com/archives/C5219G28G/p1752724963806699?thread_ts=1752681385.676609&cid=C5219G28G) as the likely cause.

**Actions proposed**
- [ ] To exclude the test at Adoptium.
- [ ] To raise an upstream issue at OpenJDK, which includes:
- The problem.
- A proposal to skip the test on platforms affected by JEP 351.
- A proposal to escape the hanging loop and to produce an informative error message.
- [ ] To write the code for the above proposal.
- [ ] To wait for the proposal to be merged.
- [ ] To unexclude the test at Adoptium.

**Links**
- Original failure: https://ci.adoptium.net/job/Test_openjdk17_hs_extended.openjdk_x86-64_linux/249/
- Rerun on RHEL 7: https://ci.adoptium.net/job/Grinder/13622/
- JEP 351: https://openjdk.org/jeps/351
- Test code (hanging line): https://github.com/openjdk/jdk17u/blob/162dbac82cf31c6948414944af836187aff9e6ca/test/hotspot/jtreg/gc/z/TestUncommit.java#L85

Start with test/hotspot/jtreg/gc/z/TestUncommit.java at line 85 and reproduce the timeout on RHEL 6, then inspect src/hotspot/share/gc/z/zPhysicalMemory.cpp around the uncommit handling. Compare the failing RHEL 6 run with the RHEL 7 and Ubuntu results and the JEP 351 behavior. Done means the affected platform is handled, the loop exits with an informative failure, and the Adoptium exclusion and later unexclusion are addressed.

Written by the indexing model from the issue text.