ts_runtime: bound GLR stack-merge recursion to prevent stack overflow on pathological input

[halindrome]

Split out of #461 at maintainer request: patches to the vendored tree-sitter runtime (internal/cbm/vendored/ts_runtime/) warrant a separate decision from ordinary language-extraction code, so filing this independently.

Problem

The GLR stack-merge in internal/cbm/vendored/ts_runtime/src/stack.c recurses without a depth bound. On deeply / pathologically nested input the recursive merge can overflow the native stack — most likely on Windows, where the default thread stack is smallest.

Proposed fix

Bound the GLR stack-merge recursion depth, degrading gracefully past the cap (bounded merge — no incorrect parse), plus a tests/test_stack_overflow.c regression that uses a fork harness to isolate the crash from the rest of the suite.

Prepared commits on halindrome/codebase-memory-mcp (branch perl-lsp-semantic-resolution, pre-cleanup history):

• 064a6130 — fix(ts-runtime): bound GLR stack merge recursion to prevent Windows stack overflow
• 560f70a1 — test(perl-lsp): use fork harness for deep-nesting test to avoid thread-local parser leak

Provenance

Self-contained depth guard in the vendored runtime; no upstream-grammar regeneration involved. Happy to open a PR against whatever branch / process you prefer for runtime patches.

[DeusData]

Thanks for splitting this out from the Perl PR. Triage: vendored runtime hardening bug, normal priority.

A tree-sitter runtime patch needs separate provenance and risk review, as noted earlier. The acceptable shape is a narrow recursion cap with graceful degradation plus a crash-isolating regression, with no unrelated runtime behavior changes.