Include API actions in JSON findings

[John-David Dalton (jdalton)]

LLM Description written by Codex:gpt-6-luna

Carry the Socket API's resolved action into each selected alert row in standard JSON. The new action field preserves the API value and is null when unavailable; legacy Issue serialization, equality, existing alert selection, links, and CLI process exit behavior remain unchanged.

Why?

JSON consumers need the action Socket resolved for a finding to present consistent remediation without changing existing CI behavior. Strict blocking continues to include unchanged error and warning findings, while standard output continues to use the existing selected rows.

Public Changelog

Standard Socket JSON now includes the API action on each selected finding.

---

Note

Low Risk
Additive JSON field and internal Issue metadata with explicit tests that selection, exit codes, and legacy serialization are unchanged.

Overview
Standard Socket JSON (--enable-json) now exposes the Socket API’s resolved policy action on each selected alert row as action (e.g. error, warn, monitor, ignore), or JSON null when the API omits it or the value isn’t a string.

The CLI reads action from API alert payloads into Issue.api_action during diff processing, then pairs selected issues with serialized rows in build_socket_json_report so action lines up with existing alert selection (including --strict-blocking unchanged findings). Issue.to_dict() and Diff serialization omit api_action, so legacy equality/serialization paths stay the same; action does not change exit codes or blocking flags. Docs in cli-reference.md describe the new field.

^{Reviewed by Cursor Bugbot for commit fe1b610. Configure here.}