chore(slurm): derive PAM module directory from target architecture

[100milliongold]

What this is

A hygiene change, not a bug fix. The current code works on ARM — this
explains why, and why the hardcoded tuple is still worth removing.

roles/slurm/vars/ubuntu.yml hardcodes the Debian multiarch tuple:

slurm_pam_lib_dir: /lib/x86_64-linux-gnu/security

On an aarch64 host this makes the play create and use
/lib/x86_64-linux-gnu/security, which is not that host's multiarch path.

Why nothing breaks today

slurm_pam_lib_dir has exactly two direct consumers, and they cancel out:

Consumer	Use
roles/slurm/defaults/main.yml:19-20	--with-pam_dir={{ slurm_pam_lib_dir }} in slurm_configure
roles/slurm/tasks/build.yml:209-219	indirect — builds contribs/pam_slurm_adopt and make installs it into the --with-pam_dir set above
roles/slurm/tasks/compute.yml:165,167,180	the absolute path written into /etc/pam.d/sshd

roles/slurm/tasks/build.yml:166,172 runs slurm_configure, so DeepOps builds
Slurm from source, and lines 209-219 then build and install pam_slurm_adopt
itself (209-213 and 215-219, both guarded by when: slurm_build):

- name: install pam_slurm_adopt
  shell: "make -j$(nproc) install >> ../../build.log 2>&1"
  args:
    chdir: "{{ slurm_build_dir }}/contribs/pam_slurm_adopt"

That make install honours the --with-pam_dir from configure. So the same
variable decides where the build puts the module and where PAM looks for it.
Both move together, make install creates the directory, and the module loads.
The PAM lines are also prefixed with -, so even a missing module would be
skipped rather than fail the login.

Why change it anyway

1. It creates a directory named for the wrong architecture. An aarch64 node
   ends up with /lib/x86_64-linux-gnu/security, outside the standard multiarch
   layout, which misleads anyone inspecting the node.
2. The sibling vars file is already architecture-agnostic.
   roles/slurm/vars/redhat.yml:2 is /lib64/security, correct on every
   architecture. Only the Ubuntu path carries a hardcoded tuple.
3. It stops being self-consistent as soon as the module is not built here —
   for example an air-gapped flow that ships a prebuilt binary, where the
   install path is decided elsewhere.
4. It breaks if --with-pam_dir goes away — switching to the distro package
   (slurm-wlm, which installs into the real multiarch path) or to any variant
   that does not pass that flag.

Change

Resolve the tuple from ansible_architecture through an explicit map. The map is
explicit rather than an <arch>-linux-gnu format string because two real
architectures do not follow that shape:

ansible_architecture	resolved directory	note
x86_64	/lib/x86_64-linux-gnu/security	unchanged from today
aarch64	/lib/aarch64-linux-gnu/security
arm64	/lib/aarch64-linux-gnu/security	input alias, see below
armv7l	/lib/arm-linux-gnueabihf/security	not armv7l-linux-gnu
ppc64le	/lib/powerpc64le-linux-gnu/security	not ppc64le-linux-gnu

A format string would have produced armv7l-linux-gnu and ppc64le-linux-gnu,
neither of which exists on those hosts. The fallback keeps format-string
behaviour for an unlisted architecture so the role does not hard-fail, and the
comment tells the next person to add an entry.

arm64 is included to match existing repository practice:
roles/nvidia-dgx/vars/ubuntu-24.04.yml:2 already tests
ansible_architecture in ['aarch64', 'arm64'].

x86_64 resolves to the same value as before, so this is a no-op on existing
clusters.

Verification

Directories checked inside real Debian-family containers on each architecture:

$ docker run --rm --platform linux/arm64 ubuntu:24.04 sh -c 'uname -m; ls -d /lib/*/security'
aarch64
/lib/aarch64-linux-gnu/security

$ docker run --rm --platform linux/amd64 ubuntu:24.04 sh -c 'uname -m; ls -d /lib/*/security'
x86_64
/lib/x86_64-linux-gnu/security

$ docker run --rm --platform linux/arm/v7 debian:12 sh -c 'uname -m; ls -d /lib/*-linux-*'
armv7l
/lib/arm-linux-gnueabihf

$ docker run --rm --platform linux/ppc64le debian:12 sh -c 'uname -m; ls -d /lib/*-linux-*'
ppc64le
/lib/powerpc64le-linux-gnu

Template rendering checked for all five map keys plus one unlisted architecture;
each resolved to the table above.