fix: require a body + matching END for PEM private-key findings

[nmatt0]

What

The secrets pass reported a private-key finding from a bare PEM begin-header with no key body. Crypto libraries (mbedtls, OpenSSL, wolfSSL) embed the PEM label strings back to back in .rodata, so any binary carrying a TLS library produced false positives. A PUBLIC KEY label sitting next to a private-key end marker was even classified as a private key.

Fixes #26.

Fix

match_pem_private now gates on three properties a real key has that a bare label string does not:

1. the begin header's own type must be a private-key type (never PUBLIC KEY / CERTIFICATE);
2. at least 64 base64 body chars must follow the header;
3. the block must close with the matching end marker of the same type.

Bounded 64 KiB scan window, all reads go through Reader, and the finding still reports the header line as a marker (never key bytes).

Tests

• New test_pem_label_false_positives: bare header; begin-then-end with no body; a PUBLIC KEY block with a real body; begin/end type mismatch; and the exact NUL-separated label layout a TLS library packs into .rodata.
• Updated the positive PEM unit tests and the id_rsa integration fixture to carry a realistic multi-line body (they previously asserted on header-only stubs).

Verification

• Full unit suite (1383 checks) and integration suite pass; clean under ASan+UBSan; secrets fuzzer 1.24M runs, no crashes.
• On two real firmware images that shipped mbedtls: the bare-label false positives drop to zero (one image went from 4 to 0; another dropped 7 including the public-key mislabel), while genuinely embedded PEM and DER private keys in the same libraries are still reported, and unrelated findings (an /etc/shadow hash) are unaffected.