auth_pam_tool loses setuid-root bit in RPM packages on Fedora 43/44 (rpm 6.x)

Ref:

• Buildbot: https://buildbot.mariadb.org/#/builders/1272/builds/26/steps/5/logs/stdio
• Zulip: https://mariadb.zulipchat.com/#narrow/channel/236699-Buildbot/topic/Fedora.2043.20-.20dev.20-.20builds.20status/with/554075935

Description:
On Fedora 43 and Fedora 44 (rpm 6.0.x), RPM packages of mariadb-server
built via CPack/CMake sometimes install auth_pam_tool_dir/auth_pam_tool
without its setuid-root bit:

    -rwx------  1 mysql root   auth_pam_tool     (broken: 0700, mysql:root)

  vs

    -rwsr-xr-x  1 root  root   auth_pam_tool     (expected: 4755, root:root)

This breaks the PAM v2 authentication plugin at runtime with:

    ERROR: Authentication with PAM v2 (pam_unix) failed

    mariadbd got EPERM from setreuid() on Fedora 43

The failure was intermittent build-to-build, tracked without a root
cause since September 2025 in the MariaDB Foundation Buildbot Zulip
channel (#Buildbot > "Fedora 43 - dev - builds status"), originally
reported under MDBF-1117.

Root cause
plugin/auth_pam/CMakeLists.txt lists the tool's containing directory
in CPACK_RPM_server_USER_FILELIST without an rpm %dir marker:

    %attr(700,%{mysqld_user},-) .../auth_pam_tool_dir

Without %dir, rpm's %files semantics treat a bare directory path as
"package this directory AND recursively everything already installed
under it." Since auth_pam_tool already exists on disk under that
directory at packaging time, rpm recurses into it while still
processing the directory's own %files line and adds auth_pam_tool to
the package a first time, stamped with the directory's attrs
(700/mysql) - before the tool's own correct
"%attr(4755,root,-) .../auth_pam_tool" line further down is even
parsed. This produces two file-list entries for the same path (rpm's
own "File listed twice" warning).

Which of the two entries wins depends on how rpm sorts and merges the
file list in genCpioListAndHeader(), which relies on same-path
entries keeping their original relative order after sorting - i.e.
sort stability - something neither qsort() (used by rpm < 6) nor
std::sort() (used by rpm >= 6's C++ rewrite) actually guarantees.

So this has always been a latent spec bug, masked by accident on old
rpm and exposed by accident on new rpm's C++ rewrite.

Fix
Add %dir to the directory's USER_FILELIST entry so rpm never
recurses into auth_pam_tool_dir at all; auth_pam_tool is then only
ever added once, from its own explicit %attr line, independent of
rpm version or file-list size:

In theory, we can base the fix at 10.11 but in practice rpm >= 6
where this issue occurs, is present since Fedora 43 i.e. MariaDB 11.8.x