Yes the list of functions + line numbers is a call-stack, it starts at the bottom where main.nut, line 75 did a function call, that led eventually to executing builder_network.nut, line 442. That line did a function call, which eventually led to executing the same file, but at line 601. There is the (long) native call, which called a function in Squirrel again, which triggered the error in builder.nut, line 97.
[ie just like you say]
You get 2 error messages for some reason. Most likely is because the native function noticed that the squirrel subroutine failed, and it passed the error + stack down for it caller to deal with it.
The other red things look like variables and their values, eg "flat" is probably a variable, and it has value "true".
In this case IsBuildableRectangle is the function that had an issue? (Line 97 is 'area.Valuate(AITile.IsBuildable);')
However "excessive CPU usage" means the native function takes too long, and that needs some explanation first.
What you want is that the AI is not eating all processor time, or the normal game would suffer. To get that, an AI gets some number of opcodes it can execute, and then its turn has passed, and the script has to wait for its next turn.
The problem is that you can't stop halfway a native function. It's either not do it this turn, or do it fully. Since it's impossible to guess beforehand how long it will take, there is only one solution, do the native call. This is what was implemented first (probably, I never looked at the squirrel code in detail). However, as AI authors got more experienced the code got bigger and more complicated, which is fine in itself (since squirrel code can be stopped at any statement), UNTIL you run such code through a native function. At that moment, the AI can't be stopped halfway, and it can eat all CPU it wants.
Some time ago, this became too much of a problem apparently, and an additional check was added that the code is not wildly beyond its allowed number of opcodes. If it is, the interpreter now throws an error "excessive cpu usage", which mostly translates to "don't make long and complicated computations while using a native function".
So while your error triggered at "isBuildableRectangle", but it is not an error at that point, it's an arbitrary "enough, now stop it!" point.
The real culprit here is either in the function that is called from the native function (which would be too long and complicated), or it is in the list items that it received (assuming the native function does a loop of some kind), which is too long.