Stream git log instead of buffering to fix ENOBUFS on large ranges

[RomainCscn]

To scan a release range, runLog ran git log through execSync, which collects the entire output in one in-memory buffer capped by maxBuffer — 1 MiB by Node default, 256 MiB since #103. When a range's output crosses the cap, Node kills git and the sync dies with spawnSync /bin/sh ENOBUFS. Crossing it depends on commit count × message size, so the same pipeline passes one day and crashes the next.

runLog now spawns git and parses the output as a stream: each commit record is parsed as soon as its %x1e separator arrives, and the raw bytes are discarded. No buffer ever holds the whole output, so there is no cap left to hit — memory scales with the parsed commits, not with whatever git prints.

Also folded in:

• git is invoked with an argument array instead of a /bin/sh command string, so --include-paths patterns (CLI- or server-provided) are no longer interpolated into a shell command where metacharacters could break or inject into it.
• getCurrentGitInfo read the HEAD message with the default 1 MiB cap inside one try/catch covering all three fields, so one oversized HEAD message failed the whole sync as "Could not get current commit". Each field now fails independently and the message read is bounded at 10 MiB.

Regression test: a git fast-import fixture drives a 270×1 MiB range past the old 256 MiB cap — it crashed before this change.

Fixes LIN-79789

[linear-code]

LIN-79789