Sequence windows after build to avoid shared action-cache race

Run 136's build job failed immediately (not a segfault) because it
and windows both clone actions/checkout@v4 and actions/cache@v4 into
the same cache directory on the runner at the same time; one job's
git fetch loses the race and ends up with a missing dist/index.js.
needs: build serializes them so they don't race on that shared cache.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

.gitea/workflows/gitea-build.yaml

@@ -33,8 +33,14 @@ jobs:
       - name: Build
         run: just release
 
-  # Cross-compiles for Windows so link breakages show up before a release
+  # Cross-compiles for Windows so link breakages show up before a release.
+  # Runs after `build`: both jobs clone the same cached actions/checkout and
+  # actions/cache repos into one shared directory on the runner, and starting
+  # them at the same time can race on that clone/fetch - one job then gets a
+  # missing or corrupted action and fails immediately (seen on run 136, not
+  # related to the odin test fix above). Sequencing avoids the race.
   windows:
+    needs: build
     runs-on: ubuntu-latest
     steps:
       - name: Checkout Repository

AGENTS.md

@@ -38,6 +38,7 @@ Commands (see `justfile`): `just run`, `just check`, `just test`, `just package
 6. **Windows builds are cross-compiled**: Odin can't link Windows binaries on Linux, so `just windows` builds objects with `-build-mode:obj` and links with `lld-link` against an xwin SDK. The VC runtime is linked statically; only Windows system DLLs are needed. New Odin core usage can need new import libs (e.g. `ole32.lib` for `os.user_data_dir`); the CI `windows` job catches this. Not yet tested on a real Windows machine.
 7. **Odin constant arrays can't be indexed at runtime**: lookup tables (`DECKS`, `LAYOUTS`, …) are `@(rodata)` globals instead of `::` constants.
 8. **Profile memory**: `profile` always allocates from the heap allocator, because the test runner frees each test's allocator afterwards.
+9. **`odin test` segfaults if the stack rlimit is "unlimited"**: the CI runner's container sets `ulimit -s unlimited`, which makes `getrlimit(RLIMIT_STACK).rlim_cur` come back as `RLIM_INFINITY` (a huge unsigned value). Odin's `core:thread` passes that straight to `pthread_attr_setstacksize`, `pthread_create` then fails, and `thread.create()` returns `nil` - which `core:testing`'s `pool_init` dereferences unconditionally, segfaulting the whole test binary (exit 139) before it prints anything. `just test` works around it with `ulimit -s 8192` before running `odin test`. Upstream Odin bug (core:thread/core:testing don't handle a failed thread creation); not our code.
 
 ## File Structure
 ```

justfile

@@ -28,7 +28,13 @@ check:
 # Run the test suite (single-threaded: the tests share the memory game's global state)
 test:
     mkdir -p {{build_dir}}
-    odin test tests -vet -define:ODIN_TEST_THREADS=1 -out:{{build_dir}}/tests
+    # If the stack rlimit is "unlimited" (RLIM_INFINITY, as some CI/container hosts set it),
+    # Odin's core:thread passes that straight to pthread_attr_setstacksize, pthread_create
+    # then fails, and thread.create() returns nil - which core:testing's pool_init
+    # dereferences unconditionally, segfaulting the whole test binary. Clamp it.
+    # (One line: just runs each recipe line in its own shell, so a separate
+    # `ulimit` line wouldn't carry over to the `odin test` line.)
+    ulimit -s 8192 && odin test tests -vet -define:ODIN_TEST_THREADS=1 -out:{{build_dir}}/tests
 
 # Optimized native build into build/<os>/, with the assets it needs at runtime
 release: