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.

[autogame-17]

Thank you for the contribution, @shaun0927. As noted in SECURITY.md and our previous triage on related PRs, EvoMap/evolver is a generated distribution mirror of an internal maintainer branch and cannot accept code PRs directly -- the public tarball carries the release integrity signature that only our release pipeline can produce correctly against the internal maintainer branch.

This specific change has been recorded and will be hand-ported into the internal maintainer branch ahead of the next release, with credit to you. Closing this PR accordingly; the underlying issue will be closed or referenced when the port lands.

If you have more suggestions we welcome them as issues (not PRs) so we can triage without creating merge-path confusion.

[autogame-17]

Hi @shaun0927 — this has shipped in v1.69.10 (release, npm).

Ported:

• src/adapters/scripts/evolver-session-end.js: the hub /a2a/evolution/record call now uses spawnSync("curl", [...argv], { shell: false }) instead of a composed shell string. apiKey, payload, and hubUrl are discrete argv entries, so shell metacharacters in any of them cannot escape.
• the signals.js _extractLLM case that the PR also touched had already been migrated to execFileSync argv form in an earlier release, so that chunk was effectively a no-op and skipped during the port.

Same attribution note as the other PRs: the public mirror is built from an internal maintainer branch. Credit is noted in the v1.69.10 release notes. Thanks again for the security-focused contribution.