Populate SecretParts on all detectors

[mcastorina]

Summary

Populates Result.SecretParts on every detector package that constructs
detectors.Result{} without it. This is the last migration step in the
SecretParts effort — after this, the checksecretparts static check
reports zero findings across all 898 detector packages and can be flipped
from warning-only to hard-fail in a one-line follow-up.

Stacks on #4913 (which introduces the checksecretparts linter and is
what surfaces the list of unmigrated detectors this PR works through).
Depends transitively on #4911 (rename) and #4912 (docs).

Approach

Two commits:

1. Single-part detectors (~695 packages) — the common case where a
   detector captures a single secret value. Adds
   SecretParts: map[string]string{"key": <value>} alongside the
   existing Raw: []byte(<value>).

2. Multi-part detectors (~125 packages) — detectors that capture
   multiple components (key/secret, client_id/client_secret, host/user/
   password, etc.). Each gets a multi-entry SecretParts map keyed by
   the component's role.

Test plan

• go build ./...
• go vet ./pkg/detectors/...
• go run ./hack/checksecretparts -fail — 898 packages scanned, 0 findings
• go test ./pkg/detectors/... — 895 packages ok, 0 FAIL

---

Note

Medium Risk
Broad mechanical change across hundreds of detector implementations; while mostly additive metadata, mistakes in per-detector SecretParts keys/values could affect downstream analyzers or deduping/verification that expects specific component naming.

Overview
Populates detectors.Result.SecretParts for detectors that previously only set Raw/RawV2, including single-value detectors (adding { "key": <value> }) and multi-part detectors (adding role-keyed maps like key/secret, id/token, url/password, etc.).

This standardizes structured secret component output across the detector suite (including some results that also use RawV2, Redacted, and ExtraData) without changing the underlying match/verification flows.

^{Reviewed by Cursor Bugbot for commit 5d5a825. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 57093b7. Configure here.}

[cursor]

ClickHelp SecretParts omits the API key component

Medium Severity

The SecretParts map for the ClickHelp detector includes "url" and "email" but omits apiKey, which is the actual secret credential. The detector iterates over three nested loops (portalLink, email, apiKey), and the apiKey is used for authentication via SetBasicAuth(email, apiKey) and is even explicitly flagged via s1.SetPrimarySecretValue(apiKey). Omitting it from SecretParts means the most sensitive component of the credential is not tracked.

 

^{Reviewed by Cursor Bugbot for commit 57093b7. Configure here.}

[mcastorina]

This is a good callout and makes me question why apiKey isn't part of the Raw??

[mcastorina]

The SecretParts match what is used in RawV2, so for consistency I want to keep this as is, even if it's wrong.

It will be a good guinea pig for supporting hash migrations in enterprise once that work is complete.