fix(dedupe): give Checkmarx Scan detailed a hash_code field list

[devGregA]

Description

Checkmarx Scan detailed is registered in DEDUPLICATION_ALGORITHM_PER_PARSER but has no
HASHCODE_FIELDS_PER_SCANNER entry. Hash computation branches on the field list alone, so with no
entry the scan type falls through to the legacy field set — which includes description. A parser
change that reworded a finding therefore moved its stored hash_code, which is precisely the
fragility a declared field list exists to prevent.

The three fields are the ones Checkmarx CxFlow SAST already uses, and for the same reason: the
detailed mode of this parser sets vuln_id_from_tool (queryId), file_path (sinkFilename) and
line (sinkLineNumber) on every finding it produces, so all three are populated and none of them
carries scan text.

Blast radius

The algorithm for this scan type is unique_id_from_tool, so candidates are looked up by vendor id
rather than by hash. This moves the stored hash_code without changing how findings are matched.
Existing findings keep the hash they were stored with until a rehash recomputes them, and the
formula change is the kind a scoped rehash repairs — as distinct from a content change, which it
cannot.

Why Checkmarx One Scan is deliberately not included

It has the same missing entry, and the obvious fix is unsafe. Its parser covers several result
families, and get_results_sca sets only title — copied from the description — and severity:
no file_path, no cwe, no line, no vuln_id_from_tool. So a list mirroring the sibling
Checkmarx Scan entry (cwe, severity, file_path) would hash those findings on severity
alone, collapsing distinct SCA findings onto one hash_code — worse than the legacy hash it
replaced. A title-based list avoids the collision but is description-derived for those same
families, so it fixes nothing.

That scan type does set unique_id_from_tool reliably, so a durable identity is already available
to it without a configured hash. Closing it properly needs per-result-family handling in the
parser, not a settings entry, and is left as separate work.

Testing

dojo.checks.check_configuration_deduplication returns no warnings with the entry in place, so
both halves of the registration agree and unittests/test_dedupe_config_checks.py's
test_shipped_configuration_is_clean holds. Verified by calling the check directly against the
edited settings, and with ruff --config ruff.toml.

Settings only. No code changes, no migration.