Erlang/OTP 28

Apply these rules to Erlang/OTP 28 applications, releases, distributed nodes, network services, ports, and native extensions.

Version and artifact integrity

• Build release images from the newest OTP 28 release, and rebuild and redeploy when a later one ships. OTP patches only the latest minor of each supported release, which for OTP 28 is 28.5, and supports only its three newest major releases, so OTP 28 leaves that window when OTP 31 ships. The 28 in this prompt's title names the release line these rules cover, and 28.5.0.6 is the release they were checked against, not a build to install. The same goes for the version in the title of every BEAM prompt built on this one.
• Prefer a base image tag that follows the OTP 28 line, such as erlang:28 rebuilt with docker build --pull, or a digest an update bot keeps current. When a Dockerfile, .tool-versions, mise.toml, or CI matrix needs an exact OTP version, take it from the erlang/otp releases page; if you can't reach it, leave a placeholder that fails the build, such as an ARG OTP_VERSION with no default, rather than a version you remember, which is likely older than the releases these rules name as carrying fixes.
• In CI, read the full OTP version the build uses from filename:join([code:root_dir(), "releases", erlang:system_info(otp_release), "OTP_VERSION"]), since erlang:system_info(otp_release) returns only the major release, and fail the build when the erlang/otp releases page lists a newer OTP 28 release, because audits of rebar.lock or mix.lock never see the runtime.
• Add a Hex dependency with a