tail will die of a SIGPIPE signal as soon as it tries to write to the pipe when it has no reader.
So tail will die soon after head has finished outputting its 10000 lines and exited.
Because pipes can hold some data (64kiB on Linux) and because tail buffers its output when not to a terminal (8kiB in my test) and head and tail read their input in chunks (of up to 8kiB in my tests), tail may read up to 64 + 8 + 8 kiB after the end of the 10000th line after offset before dying.
The worst case scenario is when head is slower to empty the pipe than tail is to fill it up (for instance if writing to a slow output like a terminal) and if the last byte of the 10000th line is at the start of a 8kiB block.
Then, in the end, head will have read the block with that last newline at the beginning (8191 more bytes than necessary), but is busy writing its output. tail, during that time has filled up the pipe (64kiB), has read another 8kiB block, but as the pipe is full is blocked writing to it. As soon as head writes its last line, and exits, tail will die but will have read 64kiB + 8 kiB + 8191 bytes past the last of those 10000 lines.
The best case scenario is when the last of the 10000 lines is at the very end of a 8kiB block and head reads data as soon as it's put in the pipe by tail. Then, if on the last block, head manages to read it from the pipe and exit before tail writes the next one, then tail will die upon writing the next block, so it will read only 8192 bytes past the end of that 10000th line.
That assumes somefile is a regular file. It could terminate sooner if somefile was some king of special file that trickles one byte at a time for instance (like a pipe from a while :; do echo; done)