refactor(darwin): gate securityd gcore keychain dump behind keychain_gcore build tag

[drogers0]

Summary

Mirrors the abe_embed treatment of the Windows ABE payload (#575) for the macOS
CVE-2025-24204 securityd-dump path, so the sensitive code is opt-in at build time
instead of always compiled into every darwin binary.

• Retag masterkey/gcoredump_darwin.go from //go:build darwin to
  //go:build darwin && keychain_gcore. All of the gcore/vmmap/Mach-O scanning
  code, plus its helpers (findProcessByName, scanMasterKeyCandidates,
  findMallocSmallRegions, getMallocSmallRegionData, addressRange,
  byteSliceToString, homeDir/loginKeychainPath) is used only in this file,
  so it moves under the tag cleanly.
• Add masterkey/gcoredump_stub_darwin.go (//go:build darwin && !keychain_gcore)
  providing DecryptKeychainRecords() that returns an error — same stub/real split
  as crypto/windows/payload/{stub,embed}_windows.go.

GcoredumpRetriever (struct + RetrieveKey) stays unconditional in
retriever_darwin.go; its single caller of DecryptKeychainRecords() already treats
any error as a silent fallthrough to the next tier (the "needs root" case), so the
default build just falls through to KeychainPasswordRetriever /
SecurityCmdRetriever exactly as a non-root run does today. No behavior change for
the native-Keychain path.

Why

The securityd-dump code (byte-scanning securityd memory via a gcore core dump)
is the part of the darwin build that gets flagged in security audits and antivirus
scans (cf. the recurring reports #623, #497, #469). It only helps a root caller,
which is a rare path. Making it opt-in via -tags keychain_gcore means the default
go build ./... — and anything importing HackBrowserData as a library — ships
without the exploit code or its identifying strings, while release/CLI users who want
it opt in exactly like -tags abe_embed.

Note for release builds

This PR is the mechanism only (as #575 was for the payload; #590 wired the release
tag separately). The darwin binary in .goreleaser.yml (id: hack-browser-data)
carries no tags, so with this change official darwin releases would be gcore-off by
default. If you want release parity with today, add tags: [keychain_gcore] to that
build (or a dedicated darwin build id) — happy to fold that in here or leave it to a
follow-up, your call on release policy.

Test plan

• go build ./... (darwin, default) — no securityd/gcore code linked
• go build -tags keychain_gcore ./... (darwin)
• GOOS=linux GOARCH=amd64 go build ./...
• GOOS=windows GOARCH=amd64 go build ./...
• go vet ./masterkey/... default + -tags keychain_gcore
• go test ./masterkey/... default + -tags keychain_gcore — pass
• Signature check on the built CLI: default binary has 0 matches for
  securityd, kern.proc.all, MALLOC_SMALL, scanMasterKeyCandidates,
  findMallocSmallRegions; the -tags keychain_gcore binary has all of them.
• golangci-lint run / typos — not run locally; deferring to CI.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 73.12%. Comparing base (4cbf7f8) to head (33c76eb).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #629   +/-   ##
=======================================
  Coverage   73.12%   73.12%           
=======================================
  Files          69       69           
  Lines        3215     3215           
=======================================
  Hits         2351     2351           
  Misses        640      640           
  Partials      224      224           

Flag	Coverage Δ
unittests	73.12% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[moonD4rk]

LGTM! Thx