bug fix: do not include last internal header word of DecReport raw bank in sort -- can result in one decisions going missing....
When !3528 (merged) introduced the encoding key in the 'internal header' of the DecReportsRawbank, the 'begin' of the (unsigned ints corresponding to the) decreports moved from the 3rd to the 4th word -- but the call to sorthere was not updated to match this.
As a result, the sorting will result in the 3rd word (taskID) to be included in the sorting, and it may end up as not the 3rd word. If this happens, one other decision will end up being interpreted as TaskID -- which will result in it no longer being available as decision. In addition, the taskID will be mangled into a decision, resulting in garbage.
Presumably this has not (yet) happened in practice, as the taskID is (typically) zero, whereas a decreport has a non-zero unsigned integer representation, and thus sort will leave the taskID as first entry. However, if the taskID will ever get set to a non-zero value, this bug will kick it.
