vulnerability: fix search payload key + complete extension coverage

[maximelb]

Summary

• Bug fix: _build_search was sending {"search": <field>, ...}, but ext-vulnerability-reporting's parseSearchOp reads s["field"] — every --search-* invocation was silently dropped server-side. Switch to {"field": ...} and update the assertion that locked in the wrong shape.
• Round out coverage of the ext-vulnerability-reporting user-facing actions the CLI didn't yet expose:
  • New flags on existing commands: --include-enrichment, --filter-via-state, --normalized-package-name, --rollup-subpackages.
  • New subcommands:
    • vulnerability cve epss-history → query_epss_history
    • vulnerability finding resolve / bulk-resolve / list / reset → set_finding_resolution, bulk_set_finding_resolution, list_finding_resolutions, reset_asset_findings
    • vulnerability snapshot list → query_daily_snapshots
• Help text now mentions lc_risk as a valid --sort-by on cve list and host packages (the extension already supports it).

Wire-shape verification

Action names and JSON field names cross-checked against the extension's RequestHandlers map and request struct tags in ext-vulnerability-reporting/ext/extension.go. Reopen semantics confirmed: omitting resolution produces req.Resolution == nil in Go, which materializeFindingResolution treats as reopen.

Test plan

• Existing 62 vulnerability unit tests still pass after the search-key fix
• New tests cover every new flag and subcommand (SDK + CLI levels)
• test_cli_lazy_loading_regression.py snapshot extended with finding and snapshot subgroups
• Full unit suite passes (3216 passed, 5 skipped; 1 pre-existing unrelated toon_format import error)
• Smoke-test the new commands against a real org once the extension is rolled out

🤖 Generated with Claude Code