After the Phoenix 1.6 esbuild switch, who should pin Elixir/OTP versions for a team?

Context

Since Phoenix 1.6 replaced the webpack/Node.js asset build with esbuild (and 1.7 made Tailwind the default), the asset toolchain is now reproducible through Hex: the esbuild and tailwind packages download pinned binaries based on versions set in config/config.exs, and mix assets.setup / mix assets.deploy replace any npm step. That part of a repeatable dev environment seems settled.

The open decision

What Phoenix does not manage is the Elixir and Erlang/OTP versions themselves. mix.exs declares only a minimum Elixir requirement, so two developers (or CI) can run different OTP releases against the same codebase. The apparent options are a .tool-versions file with asdf or mise, a Nix flake, or a Docker-based environment — but the Phoenix docs do not endorse one canonical approach.

Questions

• Is there a documented or community-standard way Phoenix teams are expected to pin Elixir/OTP versions alongside the esbuild/Tailwind pins, or is this deliberately left to each team?
• When upgrading a pre-1.6 app across the webpack→esbuild boundary, should the version-pinning strategy be decided before or after the asset migration, given CI must reproduce both?
• Are there known compatibility constraints between specific OTP releases and the esbuild/tailwind Hex wrappers that a pinned setup must respect?