drmemtrace schedule file errors hit by new drcacheoff.sysnums test

Yet another issue discovered by PR #6096: it adds a large-ish test under -test_mode and the invariant checker raises 2 errors.

First, we have for 32-bit x86:
```
316: Trace invariant failure in T-1 at ref # 0: Serial schedule entry count does
316: not match trace
```
It's b/c there's no zip lib support, and the raw2trace schedule recording
is dependent on that -- despite the serial schedule not needing it (though
I guess the original point of the serial schedule file was to help with
fast forward which only works with zip). raw2trace ends up producing a
zero-sized serial file (and no cpu file).

Next, for aarch64:
```
237: Trace invariant failure in T-1 at ref # 46937: Serial schedule entry does
237: not match trace
```
I can reproduce this one too:
```
(gdb) p next
$1 = {thread = 4129782, timestamp = 13330207028197999, cpu = 48, start_instruction = 205}
(gdb) p serial[global.ref_count_]
$2 = {thread = 4129782, timestamp = 13330207028197999, cpu = 48, start_instruction = 10000205}
(gdb) p serial[global.ref_count_-1]
$3 = {thread = 4129782, timestamp = 13330207028197984, cpu = 48, start_instruction = 9999995}
(gdb) p global.ref_count_
$4 = 46976
(gdb) p sizeof(next)
$5 = 32
```
And indeed in the file it wraps around at 10M:
```
$ zcat suite/tests/tool.drcacheoff.sysnums.linux.signal_pre_syscall.4129782.9480.dir/trace/serial_schedule.bin.gz | od -t d8 -Ax -w32 | less
16efc0 4129782 13330207028197969 48 9999785
16efe0 4129782 13330207028197984 48 9999995
16f000 4129782 13330207028197999 48 205
16f020 4129782 13330207028198014 48 415
```
Investigating why that is (10M is a strange boundary).