Hi there.
It's a somewhat old thread, I know, but I happened to stumble across this and was extremely curious about it, so much so that I couldn't resist coming back to JKA modding to examine it. I would love to know if a solution was found, but I am sure if one was found it was probably different from the workaround I am about to describe, so I am going to continue to post anyway.
First I replicated your problem by simply extracting the entities and doing the onlyents recompile on q3map2, making NO changes. The problem you describe happens as described. Since no changes were made, this can only be caused by q3map2 doing something strange (also you can tell that the light entities are properly linked and it is just the surfaces not lighting properly). Or perhaps we can say that some data related to lighting is somehow being disrupted within the bsp format when q3map2 recompiles the entities and changes the size and memory positions of other things within the bsp.
Now, there may be some combination of switches to adjust the compiler which will resolve this issue, but I felt this would take a long time to figure out, plus my memory of how q3map2 works isn't what it used to be. So instead, I used a hex editor to directly modify the entities block of the bsp, which is possible since entities are stored as plain text, and this method should remove all the possible reasons for why this lighting issue occurs from the equation. Now, normally this is not the best way to edit entities because you are essentially limited to only overwriting what is there already and cannot readily change the actual size of the bsp in this way or it will break other things. However, as I recall, all light entities that are not specifically linked to other entities (i.e., lights without targetnames) are only used during the lighting stage of the compile, and after the lighting is already compiled, the entity itself no longer serves any purpose. Since we are already dealing with a compiled bsp, this means we can just find some existing lights (they must not have targetnames!) and simply overwrite them with the hex editor to insert a couple new entities to achieve the desired result.
Below is an example of the change I made (I used HxD as my hex editor of choice). I just did a search until I found a grouping of a few unlinked lights and started overwriting them, being careful to preserve syntax and not touch any other entities. Do note that the characters that appear as dots (.) are infact hex 0A (line separator) and should be inserted in the left side this way; the rest can be typed normally on the right side where plain text is displayed.
I purposely made it a little bit more complicated than necessary (using target_relay) just to provide some margin for space where you might want to customize the specific behavior or conditions by which this triggers (this is also what the "emptyfield" keys are accomplishing, and taking up space so that we reach where the next ent begins seamlessly). Also, I only downloaded part1 and not part2 of this map for testing, so I had the levelchange point to another SP map just so I could confirm that it worked. The end result is that the lighting in the section in question works exactly as it should, and upon killing the AT-ST at the end, the level immediately changed (based on the "cin1" targetname which I figured out from browsing the map entities). For full disclosure, I will say that for testing this workaround, I did noclip through the map to get to those sections and didn't play through the whole thing. Also, I tested on openjk, although I would expect this kind of change to work perfectly fine on base jasp.exe too.