v0.32.0

Finding evidence carries a classification, not a prefix of the matched value

Findings rendered a shortened form of a matched credential into their own text. A shortened
credential no longer matches the full-length shapes the reporting boundary recognises, so it
crossed the boundary unmodified and was then marked as examined and clean.

Security advisory: GHSA-ccp3-g7fv-9cqr.
It carries the affected range, what to check in your own stored output, and what this release
does not close.

Measured on secure --json and check --json, counting JSON paths that carry characters of the
value after its constant vendor prefix:

channel	0.31.0	0.32.0
secure --json	4 paths	0
check --json	2 paths	0
findings[].description preview	2 paths	0

Five producers were involved, and the fifth needed a different answer from the other four. Four
rendered a fixed-width slice of the value and now emit a marker. The fifth, maskCredentialValue,
has two arms: its vendor-prefix arm is unchanged, because a vendor prefix is a constant that
identifies the vendor and says nothing about the individual value, which is the property its
existing test pins; its unknown-shape arm had no such constant to keep and was emitting the first
8 characters of the value itself, so that arm now masks in full.

No detection, scoring or exit-code change: finding counts are identical on every target exercised,
corpus goldens match byte-for-byte, and the suite is 280 files / 4111 tests green.

Also adds a security policy (SECURITY.md).

Known issues

Carried into this release, each reproducing identically on 0.31.0. None is introduced here and
none is fixed here. All four are scheduled for 0.33.0.

• fix-all reports CRED-001 HIGH from the key name alone (#539). An empty assignment
  (API_KEY=) is reported as a hardcoded credential, as is an environment variable reference.
  Confined to .env and .env.local; secure does not report these.
• secure --fix archives are scanned by the next run (#389). Counts climb on a tree where
  nothing was added, and three runs leave three plaintext copies of the credential on disk.
• harden-soul output can be penalised by scan-soul (#446). On a sufficiently poor starting
  file the command writes both a profile marker and sections that can imply a different profile,
  producing a HIGH SOUL-PROFILE-MISMATCH. The stated fix works.
• A finding on several files is reported and scored as one (#535). Failed AST findings
  are grouped by check alone, so one file survives per check for the whole scan and the rest
  are discarded. Five distinct credentials in five files score 69/100 with one file named --
  the same score and finding count as a single credential in a single file. Reproduces
  identically on 0.31.0.

What this release does not close

Several credential shapes are still not detected at all. A source file holding a plain
DB_PASSWORD, a Postgres connection string with an embedded password, a glpat- token and an
hf_ token scores 98/100 at exit 0 with zero credential findings; an AWS AKIA key in the same
shape of file scores 69/100 at exit 1. A clean secure result is not evidence that no credential
is present.