Unstable - Run modules-update on internal releases lacking redis-full

[dariaguy]

Internal-release tarballs may not bundle redis-full module sources, but the modules-update fallback was gated entirely behind custom_build, so internal releases (built with custom_build=false) never cloned them.

Add an internal template flag: keep yq version-pinning custom-only, but run the .prepared-gated modules-update for custom OR internal builds. Internal releases re-render with -s internal true at build time, so the committed official Dockerfile (custom_build=false, internal=false) stays clean and byte-identical to HEAD.

---

Note

Medium Risk
Changes release Docker build logic for internal tarballs; mis-gating could skip or over-run modules-update, but scope is CI/templates only and public release artifacts stay unchanged in git.

Overview
Internal release builds can ship Redis tarballs that omit bundled redis-full module sources, but the modules-update fallback lived only under custom_build, so those releases never cloned module sources and could fail module builds.

This PR adds an internal Jinja flag (wired through DockerfileContext and release_type on build-n-test / build-and-tag-locally / release_build_and_test). yq module ref pinning stays custom-only; make modules-update now runs for custom or internal builds when .prepared sources are missing (custom still re-clones when version overrides are set). For run_type=release and release_type=internal, CI re-renders Dockerfiles at build time with ./bin/render-all-dockerfiles.sh -s internal true, so the committed official Dockerfiles remain internal=false and stay in sync with validation.

^{Reviewed by Cursor Bugbot for commit 9967bb2. Bugbot is set up for automated code reviews on this repo. Configure here.}