refactor: replace execSync shell-string curl with spawnSync argv-array

[shaun0927]

Problem

Two places build curl command lines as shell strings and run them
through child_process.execSync, interpolating bearer tokens into
the command:

src/gep/signals.js:260-274                  curl ... Bearer ${nodeSecret}
src/adapters/scripts/evolver-session-end.js:104-109
                                            curl ... Bearer ${apiKey}

Today the interpolated values are internally sourced, so the
exploit surface is bounded. The pattern is still worth addressing:
any future change that pipes user-influenced data into nodeSecret
or apiKey turns a shell metacharacter into code execution. See
#410 for the full rationale.

Fix

Both call sites move to child_process.spawnSync with an argv array
and shell: false. Behaviour is preserved:

• Still synchronous. The comment in signals.js is retained,
  because the spin-wait loop still cannot await async fetch.
• Still uses curl, so no new dependency.
• Same timeout, stdio, and windowsHide options.

signals.js additionally reads the spawnSync return status
(res.status, res.error) to match the existing catch-all
return [] on failure. The prior code relied on execSync's
throw-on-nonzero; the explicit check is equivalent.

evolver-session-end.js imports spawnSync alongside the existing
execSync. The other two execSync call sites in that file use
git shell pipelines with 2>/dev/null fallbacks and do not
interpolate credentials, so they stay as-is.

Testing

$ node test/signals.test.js
# fail 0
# duration_ms 74.87

$ node -c src/adapters/scripts/evolver-session-end.js
(no output — syntax OK)

Unit tests covering signals pass; the credential-carrying code
paths cannot be exercised in CI without a live hub, but the
behaviour change is purely at the child-process invocation layer
(shell-string → argv array). curl still does the wire work with the
same flags, so the HTTP request emitted on the wire is identical.

Scope

Two files, +27/−18 lines. Argv-array conversion only. No new
dependency. No logic change outside the subprocess call form.

Not in this PR

• The token still appears on curl's argv, so it is visible to
  ps on Unix. Moving it to stdin via --header-file @- would
  conflict with -d - for the body; a fix requires choosing
  between the two, which is a behaviour tradeoff I did not want to
  bundle with the pure argv-ification. Happy to follow up.

Closes #410.