Stacked on top of the vulnerability_id-type change (feat/vulnerability-id-type).

Adds a Finding_CWE relationship so a finding can carry multiple CWEs, mirroring
vulnerability ids: the primary CWE stays on Finding.cwe; additional CWEs live in
the relationship and are exposed via finding.cwes. Wired through the UI, the API
(cwes field), and parsers (finding.unsaved_cwes). CWE is a weakness class, kept
out of hash_code and the cve field, so existing hash codes/dedup are unaffected.

Migrations 0279_finding_cwe (create table) and 0280_backfill_finding_cwe (seed
from legacy Finding.cwe), chained after the vulnerability_id migrations (0278).
Backfill existing findings with: manage.py migrate_cwe

The generic JSON and CSV importers emitted only a single `cwe` per finding,
so a finding could not be imported with a CWE *set*. Mirror the existing
`vulnerability_ids` handling to accept multiple CWEs:

- JSON: accept an optional `cwes` list (popped like `vulnerability_ids`,
  since it is not a Finding field). The first entry becomes the primary
  `finding.cwe` when `cwe` is not already given; the full set is kept on
  `finding.unsaved_cwes`. Mixed int / "CWE-<n>" forms are supported.
- CSV: accept a delimited `CweIds` column alongside the existing single
  `CweId`, with the same primary-plus-set behavior; merge CWE sets across
  internally-deduplicated rows like vulnerability ids.

The import pipeline persists the set via `Finding_CWE`; normalization and
deduplication happen in `finding_cwe_labels()`. The legacy single `cwe`
path is unchanged.

Adds a fabricated multi-CWE fixture and parser tests (JSON + CSV).

Mirror the existing cve/vulnerability_ids deprecation note: the single primary
cwe field is merged into the cwes set for backward compatibility and can be
removed once no longer needed.

… cached property

get_cwes() used the cwes @cached_property for the saved path; if finding.cwes was
accessed before the Finding_CWE rows were written (serializer/signal/log), it cached
an empty/partial set and the hash then used that stale value -> nondeterministic
hash_code (flaky dedup under parallel test runs). Mirror get_vulnerability_ids: read
the finding_cwe_set reverse relation directly (uncached, prefetch-honoring), falling
back to the unsaved values before save. save_cwes stores the primary cwe as a row too,
so finding_cwe_set carries the full set.

Add FINDING_FALSE_POSITIVE_HISTORY_CANDIDATE_FILTER_METHOD hook to
do_false_positive_history_batch. When configured, the per-finding candidate
list resolved by the deduplication algorithm is passed through the plugin
method before the FP decision, letting a plugin (Pro) narrow candidates by
fields excluded from the hash string but compared per pair (set-match tokens
on vulnerability_ids / CWEs). Resolved once via get_custom_method; a no-op
when unset, so default behavior is unchanged.

Tests: hook can suppress matches (drops candidates -> no FP replication) and
passthrough matches the default path.