While fixing #9222 I had a need to specify that a given call site must do both:

• omit visibility checks like the "functional" or "variable" call types
• raise method_missing errors as NoMethodError like the "normal" call type

Because InvokeSite only accepts a single CallType argument and bases both structure and exception-raising behavior on that call type, I had to introduce a new constructor path that provides a second call type to indicate the exception behavior. This is a very hacky fix that does not properly disentangle site setup from the multiple meanings of CallType.

For upcoming refactoring of indy call site logic, ensure that all CallType-related dimensions of a given site's behavior can be configured without overloading a single CallType argument.