I cannot help you answer your question, as I don’t use any LLMs to write code. But I have a possible (but not very plausable) explanation for this.
In case you haven’t read Thompson’s “Turing Award Acceptance Lecture” (and assuming you haven’t attended in 1984), the moral of his talk is: You can’t trust code that you did not totally create yourself. And he demonstrates that at the hand of extending the C compiler source with some code, creating the new compiler executable, and then removing the code, but keeping its functionality. He does so essentially by have the compiler executable noticing it is compiling the compiler source code and re-inserting the removed code piece while compiling.
Given your experience, combined with knowing Andrew’s stance on LLM/AI usage, I would not be surprised if Andrew has read Thompson’s paper, and implemented in an earlier version of the ZIg compiler a code segment such as Thompson describes. A segment that reinserts itself, when the zig compiler compiles itself even (i.e. even with that code segment removed from the source)
And assuming the code segment also notices that the compiler is used to generates code for a javascript runtime. And if so, inserts in that runtime, during compilation, code, that notices that it (the run-time) is used in interaction with LLMs. That code in the run-time sees you interact with it for working with Zig code and blocks its functionality.
Far fetched and unlikely (although I doubt it is beyond Andrew’s and the rest of the core team’s capabilities, I don’t think any of them is that devious). But if such a code segment did exist, and made it into the zig compiler, and when that was before Bun forked it. The actual source for that segment, as Thompson proves, didn’t have to be in the source code tree that they worked on, as long as they compiled it with the normal zig to start with (they might have forked when the bootstrap was C++ based).
Now that would be a good reason for them to rewrite Bun in Rust.