Parent #465; discovered while validating #821.
OrdinaryHasInstance currently falls back to matching errorName (or any engine error for Error) after the actual prototype-chain walk fails. This is a semantic workaround: a foreign-realm TypeError is reported as an instance of the local TypeError and local Error even though its constructor/prototype correctly belong to the foreign realm. The #821 cross-realm test exposed it; the ordinary call guard itself produced the correct foreign constructor.
Reproduced on pushed 4f7718d and the class-call candidate: the native witness reports foreignCtor=true, localCtor=false, foreignInstance=true, localInstance=true. The last result must be false. Reparented errors similarly must follow their actual prototype chain, not a hidden name tag.
Acceptance: remove the name-based fallback; preserve genuine Error subclass/prototype membership, foreign-realm separation, bound constructors, custom Symbol.hasInstance and abrupt prototype lookup; include regression and integration evidence. Do not weaken the #821 cross-realm assertion or replace this with another name/tag heuristic. Any exposed error-construction/prototype defect must be diagnosed independently, not masked by instanceof.