100 Percent CPU Race condition
But, the 100% CPU condition sounds like there are some wait/spinlock issues – can you run the following query from Paul Randal's blog and share the results?
That said, hints and plan guides ought to be a last resort. There are two separate root causes here.
First, the query plan appears to be sensitive to sniffed parameter values. When the query is compiled with one sniffed parameter value, the query optimizer chooses a serial execution plan based on an index-intersection strategy. This is the serial plan you originally posted.
When the query replan later recompiles (perhaps due to a change in statistics, as the database changes over time) the sniffed parameter value is different, causing SQL Server to choose a parallel execution plan based on an index scan instead. This plan is cached and reused for subsequent executions, quickly overwhelming your server with parallel queries.
The more serious second problem is that you are using scalar functions extensively, and filtering on the results. This is a major anti-pattern, because it can result in a separate function execution for each row of the index scan, and it might also severely limit the optimizer's ability to use indexes. The function calls are shown below:
I cannot over-emphasise how inefficient this is. For each of the 31,716,200 rows from the RemitItem table, five separate data-accessing function queries are executed. That is to say 158,581,000 separate evaluations before the filtering can be applied.
Notice also the implicit conversions, meaning your function inputs expect Unicode strings but MRNO is stored as something else (possibly not even a character type).
Forcing a serial plan or messing about with parallelism thresholds might buy you some time, but ultimately, a serious design and implementation rethink is needed here.