Investigate: should `syscall` be allowed from context 0

In #2296, we allowed the syscall operation to be called from context 0. As mentioned in that PR description,

>It is also worth noting that syscalls were also previously disallowed in a syscall context. In this PR we allow them, as there is no difference between
>
> - a syscall from context 0 at the start of the program (previously allowed), and
> - a syscall from context 0, where context 0 was entered due to a SYSCALL.

In other words, the old processor (`Process`) used to use the `in_syscall` register to check if `SYSCALL` should be allowed (and analogously, the constraint would check the `in_syscall` column to determine if the syscall is allowed). Hence, syscalls have always been allowed in context 0, specifically when context 0 was not entered from a syscall.

The solution in #2296 was to uniformly allow for syscalls in context 0, as there were no reason to disallow it. Though this should be revisited if we missed anything back then.

Related to the removal of the `in_syscall` column: https://github.com/0xMiden/miden-vm/issues/1681#issuecomment-3415807040

cc @bobbinth

Review PR #2296 and the related comment about removing the `in_syscall` column (issue #1681). Understand the processor's context handling and the syscall operation constraints. Determine if allowing syscalls from context 0 uniformly introduces any security or correctness issues by examining the VM's execution model and test cases.

Written by the indexing model from the issue text.