Feat/expand check results

[adkinsty]

Summary

• Add --ids flag to results list for fetching results for specific check IDs (comma-separated)
• Use ListChecks with check IDs internally to enrich contract verify scan results — previously only showed ID and status; now shows column, value, ane name of the check as well; check id, check type, dataset dqn, and check definition included in json output only.
• Extract shared renderCheckRows so both results list and contract verify produce consistent output and JSON fields
• results list table now shows: dataset, column, name (of check/monitor), value, status, date; check id, check type, dataset dqn, and check definition included in json output only.
• Add ⚠ warning symbol for warn status in table output
• Add --exact flag to results list to switch --dataset-name from substring to exact match — useful when a dataset name is a prefix of other dataset names

Motivation

The CLI had no way to look up specific checks by ID from the terminal. This is useful both directly — e.g. fetching the checks you care about without filtering by dataset — and as a building block for enriching other commands.

The main beneficiary is contract verify: scan results previously showed check IDs (uuid) and statuses from the scan response. Now the full check record is fetched via --ids, giving you column, value, and a properly sorted results table — without needing to open the UI.

results list and contract verify now share the same rendering logic, so output is consistent across both commands.

Test plan

• sodacli results list --dataset-name <name> shows correct columns
• sodacli results list --ids <id1>,<id2> returns specific checks by ID
• sodacli results list -o json includes id, definition, type fields
• sodacli contract verify <file.yml> shows enriched results with column, value, and check name
• warn status shows ⚠ warning in table output

🤖 Generated with [Claude Code](https://claude.com/claude-code

[santiviquez]

Hi @adkinsty I pushed a small follow-up that drops --exact and makes --dataset-name always do an exact, case-insensitive match against the fully qualified name.

My reasoning: having a boolean flag that flips the meaning of another flag is an API smell. --dataset-name "orders" alone vs --dataset-name "orders" --exact means two different things, and which is the default is not obvious and would have have to memorize.

Substring discovery still is available when doing dataset list --filter <query>

The rest looks good, let me know if this makes sense for you use case. If so, I'll merge it.

[adkinsty]

Sounds good to me