fix(scan): validate SEVERITY_THRESHOLD and RISK_SCORE_THRESHOLD

[joeymussalli]

Both threshold inputs were fed straight into the gate with no validation, and each one broke in a different direction when it was handed something other than a canonical value.

SEVERITY_THRESHOLD was compared through sev_rank, whose *) catch-all arm returns -1. Since -1 is <= every real severity, an unrecognised threshold did not disable the gate or raise an error -- it became the LOOSEST possible comparison. Against a repo whose only finding is info, SEVERITY_THRESHOLD=critical passed (exit 0) but HIGH, High, criticl and ' high' all failed the build with "max severity info >= threshold HIGH". Uppercase is a very plausible thing to write in YAML and a stray space is trivially easy, so the strictest-looking config silently became the loosest: the build broke on info-only findings, which docs/EVALUATION.md says should "never fail a build on their own", and the printed reason was self-refuting, so the user had nothing to diagnose from.

RISK_SCORE_THRESHOLD failed the other way. [ "$RST" -gt 0 ] 2>/dev/null swallowed ['s exit-2 on a non-integer, so the whole condition went false and the risk gate vanished with no warning at all. With risk 90, RISK_SCORE_THRESHOLD=50 failed as expected, while abc, 1e2 and -1 all passed silently. 1e2 is plausible hand-entry and an unexpanded ${...} from CI templating is a realistic source of garbage, so a misconfigured pipeline could report green while enforcing nothing.

The asymmetry is the point: bug 1 failed closed (annoying but safe), bug 2 failed open (dangerous). Both are now resolved in the safe direction -- a threshold this script cannot interpret is treated as a build-failing configuration error rather than being guessed at, since silently downgrading either one to "no gate" is exactly the failure mode that lets bad code through. The errors are raised via the existing FAIL/REASONS machinery rather than an early exit, so trustabl-summary.md is still written and the reason lands in the report artifact alongside the usual gate reasons.

Changes, all confined to the gate block near the end of the script:

• Add a trim_ws helper and trim both thresholds, so surrounding whitespace cannot change how a value is interpreted.
• Lowercase SEVERITY_THRESHOLD, then reject any value that sev_rank cannot rank instead of letting the -1 arm loosen the gate.
• Require RISK_SCORE_THRESHOLD to be a non-negative integer; drop the 2>/dev/null that hid the malformed-input case.
• Print a specific ERROR line to stderr naming the offending value and the accepted set for each.

Currently correct behaviour is unchanged: none and empty still disable the severity gate, canonical lowercase severities gate exactly as before, RISK_SCORE_THRESHOLD=0 and empty still disable the risk gate, and ' 50', '50 ', '+50' and '0050' (which already worked) still do. A whitespace-only value for either input is now treated as unset rather than as garbage, matching the documented "empty disables" meaning.

Verified with bash -n and with a harness that sources the real gate block out of the script and drives it with synthetic scan results, over canonical, uppercase, title-case, typo, leading/trailing-space, empty and none severities and over valid, abc, 1e2, -1, 5.5, 0, unexpanded-${...} and space-padded risk values. Confirmed end to end that a genuine high finding with SEVERITY_THRESHOLD=high still exits 1, that SEVERITY_THRESHOLD=none still exits 0, that an info-only repo now passes under HIGH/High/' high', and that a config error exits 1 with the reason recorded in trustabl-summary.md. No network calls and no real scan were involved.

[joeymussalli]

Closing in favor of #6 (bradAGI), which already covers misconfigured SEVERITY_THRESHOLD / RISK_SCORE_THRESHOLD. Leaving contested SARIF work (#16) alone.

[joeymussalli]

Reopened — closed earlier by mistake. Leaving this up per author request.