[Feature] Add --json output mode to `nango dryrun` for CI and agent-harness consumption

[fuleinist]

Problem

nango dryrun (and the related sync-debug flow in dryrun.service.ts) prints its results through chalk to stdout. The output mixes progress logs, formatted request/response dumps, color codes, and chalk.gray('no output') strings. A user — or a CI step, or an agent harness like Claude Code / Codex — cannot parse the action output, log counts, or error code without scraping formatted text.

For local interactive use this is fine, but it blocks the most common automation paths:

1. CI pipelines that want to assert the dry-run produced a specific number of records or didn't error.
2. Agent harnesses (Claude Code, Codex, Cursor) that call nango dryrun as a tool and need to feed the result back into a model.
3. PR-check bots that diff nango dryrun output against a baseline.

Today the only output-format signal is --validate / --save-responses (writes to a fixed test-fixture file). There is no structured "what happened" channel on stdout.

Proposed change

Add a --json flag to nango dryrun that, when set:

1. Suppresses chalk colors, the inquirer prompts, and the spinner.

2. Emits a single JSON object to stdout of the form:

   {
     "ok": true,
     "error": null,
     "output": <action output or sync records>,
     "logs": { "counts": {...}, "messages": [...] },
     "requests": [...],
     "diagnostics": <only when --diagnostics is set>
   }

3. Exits with the same codes as today (DryrunError, CompileError, etc.) so CI can detect failure without parsing JSON.

Implementation sketch (mirrors how --diagnostics and --save-responses are already wired in packages/cli/lib/index.ts and packages/cli/lib/services/dryrun.service.ts):

• Extend RunArgs in dryrun.service.ts with outputJson?: boolean.
• In the existing console.log / console.error call sites, branch on this.outputJson — emit process.stdout.write(JSON.stringify(...) + '\n') instead of formatted text.
• Add the flag to the commander definition in packages/cli/lib/index.ts next to --diagnostics.
• Add a small section to docs/integrations/cli.md covering --json and the schema.

Distinct from --save-responses (which writes a fixture for replay) — --json is the runtime result in a single machine-readable envelope.

Use case

A .github/workflows/integration-validate.yml job runs nango dryrun my-sync <connection> --validate --json on every PR. The job:

1. Pipes the JSON through jq to assert .ok == true and .logs.counts.success > 0.
2. On failure, posts the parsed error.code and the first 5 logs.messages as a PR comment.

Today the same job has to either run the dry-run twice (once with --save-responses and parse the fixture) or grep through chalk-colored output. Both are fragile and break on every minor CLI text change.

Why this is small

The data is already computed in dryrun.service.ts — resultOutput, logMessages.counts, validation errors, diagnostics. The change is: collect them into one envelope, branch on the new flag at the print sites, add one CLI option. No new dependencies, no schema migration, fully backward compatible.

[linear-code]

NAN-5830

[ryanmettler]

Hi — if this is still open and unclaimed, I'd be glad to take it on. Before writing any code I wanted to
align on the design, because looking at dryrun.service.ts I think there's one important refinement to
the sketch above.

One change from the proposed approach: the sketch suggests branching on this.outputJson at each
console.log/console.error site and writing JSON.stringify(...) there. Because run() prints from
~30 different sites (progress, request/response dumps, logMessages.counts, the validation block, the
diagnostics path, the catch), doing it per-site would emit ~30 separate JSON fragments to stdout — which
breaks the issue's own "a single JSON object" goal and isn't jq-parseable. I'd instead:

• Accumulate the result into one envelope object as the run proceeds, and process.stdout.write it
  once at the end (success and error paths).
• Keep stdout reserved for the JSON envelope only; route human/progress/chalk output to stderr
  (or suppress it) under --json, so a CI step can do nango dryrun ... --json | jq cleanly while still
  seeing progress on the terminal. (Happy to suppress entirely instead if you'd prefer — your call.)
• Preserve today's exit codes exactly (DryrunError/CompileError/etc.), so CI detects failure
  without parsing the body, and put the structured failure in error: { code, message } on a non-zero exit.

Proposed envelope (open to your naming — this mirrors the data already computed in dryrun.service.ts):

{
  "ok": true,
  "error": null,                       // { code, message } on failure
  "output": <action output | sync records>,
  "logs": { "counts": { ... }, "messages": [ ... ] },
  "requests": [ ... ],                 // when --save-responses-style capture is on
  "diagnostics": { ... }               // only when --diagnostics is set
}

Mechanically I'd: add --json to the commander definition in packages/cli/lib/index.ts (next to
--diagnostics), thread outputJson?: boolean through RunArgs, gate the existing print sites, assemble
the envelope, and emit once. Plus a short docs/integrations/cli.md section and a CLI unit test asserting
a single valid JSON object + preserved exit code.

A couple of design checks before I start:

1. Scope — just nango dryrun, or should the related sync-debug flow in dryrun.service.ts get the
   same treatment in this PR?
2. --json × --validate / --diagnostics / --save-responses — fold validation errors and
   diagnostics into the envelope (as above), and keep --save-responses's fixture file write unchanged?
3. stderr vs. fully-silent for progress/log output under --json — any preference?

If the approach and envelope look right to you, I'll open the PR. Thanks!