Add configurable path for Redis/Gateway build temp directories

[mazam32-itential]

Summary

• ansible.builtin.tempfile does not honor remote_tmp/ansible_remote_tmp. On hosts where /tmp is mounted noexec, the Redis source build's configure/make steps fail with "Permission denied" since they need to execute files from that directory.
• Added an optional path for each role's build/staging tempfile task: redis_build_temp_dir_path and gateway_build_temp_dir_path.
• Both are sourced via | default(omit) rather than a literal /tmp default, so when unset the path argument is omitted entirely and the module falls back to its own normal directory resolution (TMPDIR/TEMP/TMP env vars, then /tmp, /var/tmp, /usr/tmp) — identical behavior to before this change, including for any host that happens to have a non-default TMPDIR set for root.
• Documented both new variables in roles/redis/CLAUDE.md / docs/redis_guide.md and roles/gateway/CLAUDE.md / docs/itential_gateway_guide.md.

How this was tested

Tested against a live EC2 instance (Rocky Linux 9):

Baseline (no override set): confirmed via -v output that the tempfile task's path resolved through the default(omit) fallback, landing on /tmp as before. Redis 7.4.6 built and installed successfully.

Negative test: created a real noexec tmpfs mount (mount -t tmpfs -o noexec,size=200M tmpfs /mnt/noexec-test), forced a Redis rebuild, and set redis_build_temp_dir_path to that mount. The build failed exactly as reported:

sh: line 1: ./mkreleasehdr.sh: Permission denied
/bin/sh: line 1: ./configure: Permission denied

Positive test: same setup, redis_build_temp_dir_path set to /var/tmp instead. Build succeeded, confirming the override fixes the reported failure.

Gateway: ran the full Gateway install with gateway_build_temp_dir_path pointed at the same noexec mount — it succeeded end-to-end (failed=0, automation-gateway.service active). Gateway's pip install only reads the staged .whl file rather than executing anything from that directory, so it was never actually vulnerable to this failure mode. Its variable is added for the same configurable control, not because a reproducible bug exists there — flagging this explicitly rather than implying an equivalent fix.

Lint: ansible-lint on all changed task/doc files passes clean (0 failures; pre-existing unrelated warnings elsewhere unchanged).

Test plan for reviewer

• Confirm hosts that don't set either new variable see no behavior change
• Optionally reproduce the noexec failure/fix on a test host per the steps above
• Confirm Gateway's variable is documented as precautionary rather than fixing a known Gateway-specific bug