The script resources are subdivided into a few different blocks, such as local variable storage (including initial values), class and instance definitions, actual script code, a pool of string literals, a pool of said specs, and probably one or two other types I forgot.
The decompiler can tell that the lookStr value is a pointer because it's a fairly high value (same way Print can tell a string literal from a text resource tuple), and it can tell that it's a string because said value matches a location in that resource's string literal pool. By the same token, it can recognize said specs. If it's none of those kind of thing even if it's a sufficiently high value, it's probably an integer constant.
In the later versions with the split SCR/HEP resources, all of those things went into the HEP resources except for the actual script code, which went in the SCR resources, while the said spec block was removed.
Certain later versions of Sierra's compiler allowed lackluster type tagging, where a selector was tagged as an int or an id. I'm not sure how much the compiler actually cared.
And you're right to think it might mistake a value for a string! I'm not sure what would happen and would like to find out. I'll get back to you.
Test results
(= test $02BD) where $02BD is also a string literal's location doesn't break much because that would emit an LDI opcode (Load Immediate), while assigning a string pointer would use LOFSS (Load OffSet to String?) and the decompiler knows what to do here.
However, as I expected, changing one the test room's cardinal exits to $02BD does confuse the decompiler into thinking it's a string.
HOWEVER HOWEVER, changing it to $02BE, just one byte off, made it an integer again! Apparently the decompiler is smart enough to check if it's the very start of a string. So no such risk.
