Solution:
When creating a new thread, pthreads will make a copy of all functions (as well as classes, interfaces, traits, etc) available from the current environment (unless selective inheritance flags have been used in Thread::start, of course). This means that if you have already included the wp-load.php file, then you do not need to include it again inside of the new thread (in Thread::run). (If you haven’t included this file yet, then what you’ve done is fine.)
Looking at your example code, you are assigning the $emails parameter from the constructor to the $this->emails property. However, the foreach is attempting to iterate over the $this->email_array property, which will simply be null. So from your example code at least, it looks like the problem is with what property you’re accessing, rather than the wp_mail function not being accessible.
With all that said, it does look like you’re attempting to use pthreads in a web server environment. This has its own ramifications and is simply a bad idea. You’d be better off queueing such tasks (via RabbitMQ or something) to handle them elsewhere.
UPDATE (from your update):
Having a brief look through the WordPress codebase, I can see that threading simply isn’t going to work here. The codebase is just incredibly unfriendly to such concurrency techniques.
The update_option function will not work because it relies upon a global DB connection. This connection cannot be used across different contexts (threads) – instead, a new connection must be created per thread.
The wp_mail function uses the get_bloginfo function, which in turn uses the get_option function, which in turn has a global for DB access. So you’re going to have the same problem there as above.
Given the ubiquity of globals in the WordPress codebase, threading is simply not going to work here…