Decide how shared EngSys scripts (eng/common) should reuse azure-rest-api-specs shared primitives (exec.js)

[helen229]

Context

On PR #16052 (Vally eval CI phase-1), @danieljurek raised a design question on the local invokeGit wrapper in eng/common/scripts/eval/sync-eval-git-repo.js:

We do have primitives in azure-rest-api-specs for common operations https://github.com/Azure/azure-rest-api-specs/blob/main/.github/shared/src/exec.js ... They were written with specific assumptions and not immediately available here but they could be useful to avoid duplication.

@mikeharder -- How can/should shared EngSys scripts make use of the work in the REST API Specs ... I think many of the functions there could be useful here.

Original thread: #16052

Current state

The eval harness under eng/common/scripts/eval/ uses a minimal ~4-line local invokeGit wrapper around spawnSync. It intentionally does not import the specs exec.js primitives because:

• eng/common has no cross-repo dependency on the azure-rest-api-specs .github/shared package.
• Those helpers carry specs-repo-specific assumptions.

A code comment documenting this tradeoff was added in PR #16052.

Question to resolve

How should shared EngSys scripts (eng/common/**, synced into every language SDK repo) reuse common utility primitives (exec, logging, etc.) that already exist in azure-rest-api-specs/.github/shared?

Options to evaluate:

• Publish the shared primitives as an npm package consumable by eng/common.
• Extract a small shared exec/util module into eng/common itself (travels with the sync).
• Keep per-consumer minimal wrappers (status quo).

Scope

Cross-cutting EngSys decision; out of scope for PR #16052. Deferred to @mikeharder.