Start by reading the identifier as what it is rather than as a message, because it is not one.
An init_<something>_esm symbol is a module initialiser the bundler generated. When a bundle is split into chunks, each module gets a small function whose job is to run that module's top-level code exactly once, and other chunks call it before touching anything the module exports. The name is assembled from the module's path, which is why the library's name is sitting in the middle of it.
So the identifier tells you which module failed to be initialised. It does not tell you who broke it, and in this class of bug it is almost never the named library. The library is the victim: it is simply the one that happened to be reached first through a chunk boundary the bundler got wrong.
That also explains your two clues, and they are the strongest evidence you have:
- Turning off code splitting fixes it — because with one chunk there are no cross-chunk initialiser calls at all. The bug cannot express itself.
- The named library did not change — because the fault is in the thing that decides how modules are grouped and in what order they wake up.
Which points at exactly one place: the bundler underneath your build tool. Modern build tools are a thin layer over a separate bundler, and a patch release of the outer tool routinely pulls in a new version of the inner one. Your one-patch bump was not a one-package bump.
Check what actually moved. The lockfile diff for that upgrade will show the bundler's version changing alongside the tool's, and that is your real suspect.