The last thing I did in that branch before merging it was build a fresh zig1.wasm with the latest tip of the branch, so the commit order is not necessarily correct there for the purposes of reproducing.
You probably need one of the other fixes from the branch in order to avoid tripping that bug, particularly the one in Sema.zig that adds the line:
try sema.queueFullTypeResolution(result_ptr);
This is the case for many of the branches if you are trying to create a bootstrap chain. You might need to solve a little puzzle in each branch to figure out how to rebuild zig1.wasm.
For the real world purposes of bootstrapping, the best solution is for a third party to implement a zig interpreter that assumes -target wasm32-wasi and uses pub const dev = .bootstrap; in the config options in order to produce zig2.c and continue the build from there. This interpreter could be written in Lua or Lisp for example, and only needs to be able to interpret exactly the latest tagged release of Zig. Any tricky one-off functions could be hacked around in this interpreter since it is a bespoke interpreter for this one codebase. Such hacks would not compromise the goal of the interpreter, which is to ensure that zig1.wasm has no hidden logic.