tests: test_stops must not assume /tmp exists (fixes the windows job)

My test_stops.c called mkdtemp("/tmp/coli_stops_XXXXXX"). These binaries are
built by MinGW into NATIVE Windows .exe files, which resolve Windows paths —
"/tmp" is not one, so mkdtemp failed ENOENT and `make check` went red on the
windows job the moment #143 gave us cross-platform CI.

Now a relative template in the CWD, which is what test_compat_direct.c already
does (`#define TMPF "test_direct.tmp"`). test_uring.c uses /tmp but is
Linux-only by construction (Makefile guards it behind $(LINUX)); I copied the
wrong neighbour.

Worth being precise about what this was, because the red job looked scarier
than it was: Windows is fine. `make check` built the engine, ran the whole C
suite, and passed everything else — test_i4_grouped, kv_alloc, compat_direct —
before tripping on my temp path. The CI caught a bug in the test, not in the
port. That is #143 earning its keep on day one.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

c/tests/test_stops.c

@@ -65,7 +65,11 @@ static int expect(const char *what, int id, int want){
 
 int main(void){
     int fail=0;
-    char dir[]="/tmp/coli_stops_XXXXXX";
+    /* Relative to the CWD, like test_compat_direct's TMPF — NOT "/tmp/...".
+     * These binaries are built by MinGW into native Windows .exe files, which
+     * resolve Windows paths: "/tmp" is not one, so mkdtemp there fails ENOENT
+     * and the whole `make check` goes red on the windows job (and only there). */
+    char dir[]="test_stops_XXXXXX";
     if(!mkdtemp(dir)){ perror("mkdtemp"); return 1; }
     write_tok(dir);
     char tkp[512]; snprintf(tkp,sizeof(tkp),"%s/tokenizer.json",dir);