fix: filter structured-text false positives from the generic-secret detector

[nmatt0]

What

The generic-secret detector (keyword like password/secret/api_key + a high-entropy value) produced almost entirely false positives on firmware that ships a web UI. Its value alphabet and gates (length + entropy + a small wordlist) did not distinguish an opaque credential from structured text — printf/URL format strings, JavaScript object access, and localization strings are all long and diverse enough to clear the entropy gate.

Fix

Add a value-shape filter (generic_value_is_noise) applied to the extracted value, rejecting it when it is:

1. a format string — % followed by a printf conversion (%s, %02x, …);
2. an assignment/query shape — an interior = or any & (a trailing run of = is treated as base64 padding);
3. a no-digit word/identifier chain — after trimming non-alphanumeric ends, the core is only letters and ./_/- separators (dotted member access, snake/camel identifiers, hyphenated/localization words).

Real credential values carry a digit or base64 density and are kept.

Trade-off

Precision-first at the pattern tier: the one accepted false negative (documented in the code) is a purely-alphabetic hardcoded password with no digit.

Validation

Measured before/after across a set of real firmware images:

• False positives from web/source/localization content drop to zero — e.g. a router web UI 7 → 0, an NVR web UI 32 → 0, a camera web UI 4 → 0.
• Real values are retained — a device's base64-encoded config credentials 29 → 29, and a JWT-shaped access token still matches.

Tests

test_generic_secret_shape covers the three reject shapes — including the leading/trailing-punctuation and consecutive-separator variants seen in minified JS — plus two must-keep positives (a JWT-shaped token and a digit-bearing password). Full unit suite (1397 checks) and integration suite pass; clean under ASan+UBSan; secrets fuzzer clean.