fix: clj-holmes crash on large repos; make semgrep findings visible

[arootroatch]

Two regressions from replacing clj-holmes-action, both surfaced by the first
real consumer run (cleancoders.com run 30379331916).

1. clj-holmes crashed and blocked a production deploy

IllegalArgumentException: Value out of range for int: 35050732419
  progrock.core$interval_str -> clj_holmes.logic.progress

Its progress bar overflows an int computing an ETA. Exit 255, no SARIF written
at all. Silent on small repos, fatal on ~1300 Clojure files. Those nonsense
ETA: 15823642:26 values in every clj-holmes log were this bug not yet tipping
over.

The stock clj-holmes-action always passed --no-verbose; dropping that flag
when replacing the action reintroduced it. With the flag, the same scan on
cleancoders.com exits 0 with 0 findings — so a progress-bar bug, not a
security finding, blocked a deploy.

Also guards a missing SARIF explicitly rather than letting jq fail obscurely
on a file that was never created.

2. semgrep findings were invisible

The job went red and the log said, in full:

✅ Scan completed successfully.
 • Findings: 5 (5 blocking)
Ran 290 rules on 1391 files: 5 findings.
##[error]Process completed with exit code 1.

Five findings, no indication what or where. With --sarif --output the detail
goes to the file, so --error gave a red job and an unactionable log — the same
defect fixed for clj-holmes in the previous PR and missed for semgrep in the
same commit.

Now prints severity, rule, file and line, and computes the exit code here:

  [error] detected-jwt-token  spec/clj/cleancoders/jwplayer_spec.clj:37
  [error] detected-generic-secret  src/clj/cleancoders/config.clj:118
  [warning] cc-generic-catch  src/clj/cleancoders/db_browser/engine.clj:58
  [warning] cc-generic-catch  src/clj/cleancoders/mfa.clj:218
  [error] cc-cljs-innerhtml  src/cljs/cleancoders/contact.cljs:224
semgrep: 7 finding(s), 3 blocking

Only error-level findings fail the job. Severity lives on the rule
(tool.driver.rules[].defaultConfiguration.level), not the result — semgrep
leaves results[].level null — so the jq joins them. cc-path-traversal and
cc-generic-catch are WARNING on purpose and the README promises they do not
block; counting every result would have broken that promise. cleancoders.com has
7 findings but only 3 blocking.

Verification

Reproduced both against cleancoders.com locally: without --no-verbose, exit 255
and no SARIF; with it, exit 0 and a valid report. The new jq was validated
against the actual SARIF artifact from the failing run.

v1 needs retagging after merge — cleancoders.com deploys stay blocked until it
moves.

🤖 Generated with Claude Code