Word-boundary regexes miss secrets on their own line inside JSON

A secret scanner using \b anchors silently under-reports on JSON or JSONL data. Inside a JSON string a newline is stored as the two characters backslash and n, so a credential pasted at the start of a line is preceded by the LETTER n, \b does not fire, and the match never happens. Measured on real fixture data: 16 of 28 planted credentials found, a 43 percent miss, and three of six key shapes reported exactly 1 occurrence when the file contained 4. The missed position is the worst one -- a key on its own line is the single most likely way a credential appears in a pasted config or env dump. Fix by replacing the leading \b with an explicit fixed-width alternation over real separators including the escaped ones. Two related traps in the same pass: a PEM regex matching only the BEGIN line detects the key but redacting that span leaves the entire base64 body in place, and any model asked to explain what it found will quote the secret back into its own prose, so the explanation needs scrubbing too.