[build] Remove HAVE_MSYNC guard in mmapmodule.c once nanvix/nanvix#2212 lands

[ada-x64]

Summary

PR #561 (mmap module enablement, closing #301) added a build-system workaround for the absence of msync() in libposix:

• configure.ac / configure: msync added to AC_CHECK_FUNCS.
• pyconfig.h.in: #undef HAVE_MSYNC template entry.
• Modules/mmapmodule.c:681: mmap.flush()'s call site gated on defined(HAVE_MSYNC), falling through to the existing ValueError("flush not supported on this system") path on platforms without msync.

This is a temporary divergence from upstream CPython, which calls msync() unconditionally on the UNIX branch. Once libposix exports msync() (tracked in nanvix/nanvix#2212), the guard becomes dead weight and the divergence should be removed.

Action when nanvix/nanvix#2212 lands

1. Bump the nanvix sysroot pin in .nanvix/nanvix.toml to a version that includes msync().
2. Verify autoconf detects it: after ./z setup, confirm pyconfig.h contains #define HAVE_MSYNC 1.
3. Revert the Modules/mmapmodule.c portion of the second commit in PR Enable the mmap stdlib module on Nanvix #561 — remove && defined(HAVE_MSYNC) from the #elif so the call site matches upstream again.
4. Optional: drop msync from the AC_CHECK_FUNCS list and the #undef from pyconfig.h.in. Harmless to leave, but cleaner to remove the dead probe.
5. Add mmap.flush() to test_mmap coverage (which itself depends on adding test_mmap to NANVIX_TEST_LIST — separate concern).

References

• PR Enable the mmap stdlib module on Nanvix #561 — mmap enablement, where the guard was added
• Enable mmap stdlib module (memory-mapped file I/O) #301 — original mmap enablement issue
• [libs] Implement msync(2) nanvix#2212 — msync(2) implementation in libposix