Fixes sys_change_vcore() return path

Fixes sys_change_vcore() return path

Once we unlock, we could have the calling vcore start up remotely before
we get a chance to finish the syscall (writing the syscall struct).  If
the vcore had notifs disabled, it'll start up where it left off and wait
on the syscall finishing, which is fine.  However, if the vcore starts
from scratch on a remote core, nothing will ever wait on the sysc, and
we now could be writing into the stack at some random future date.