`twistlock2hdf`: unmapped severities silently become impact 0, and hdf2ckl then marks those findings Not_Applicable

[wdower]

Twistlock scan output can contain severities that are missing from IMPACT_MAPPING in libs/hdf-converters/src/twistlock-mapper.ts:

const IMPACT_MAPPING: Map<string, number> = new Map([
  ['critical', 0.9],
  ['important', 0.9],
  ['high', 0.7],
  ['medium', 0.5],
  ['moderate', 0.5],
  ['low', 0.3]
]);

Real Twistlock reports also emit at least unassigned, unimportant, and negligible. None are in the map, so impactMapping() in base-converter.ts falls through to its || 0 default and the finding is written into OHDF with impact 0.0 — with no warning, and indistinguishable from a genuine 0.0.

Reproduce: convert any Twistlock report containing a finding with "severity": "unassigned", then run the result through hdf2ckl. The finding's stanza has STATUS: Not_Applicable.

Suggested fix: add the missing severities to IMPACT_MAPPING (unassigned and unimportant presumably map somewhere in the 0.3–0.5 band; negligible near the floor — needs a decision). The silent-miss behavior of impactMapping() itself is a separate, converter-wide issue: see companion issue #8610.

The reporters have offered matched sample reports from their corpus as regression fixtures.

[wdower]

We're going to go with: unassigned / not yet assigned / untriaged → 0.5, unimportant → 0.1, negligible → 0.1, based on Prisma's docs on how it aligns upstream vendor severity levels into Twistlock. We will update the mapper to properly catch those severities.

I also want to add a fallthrough guard so that even if an unmapped severity shows up in source data, it gets set as 0.5 impact instead of 0.0 (on the logic that 0.5 is the average and therefore the least opinionated impact level). Lots of converters already map unknown statuses to 0.5. See #8610.