refactor(darwin): make keychain gcore dump opt-in via build tag (#629)

Mirror the abe_embed treatment of the Windows ABE payload (#575) for the
macOS CVE-2025-24204 securityd-dump path: retag gcoredump_darwin.go under
'darwin && keychain_gcore' and add a 'darwin && !keychain_gcore' stub for
DecryptKeychainRecords. The default go build (and library consumers) then
ship without the exploit code or its byte signatures; the capability is
opt-in via -tags keychain_gcore, exactly like -tags abe_embed.

GcoredumpRetriever already treats a DecryptKeychainRecords error as a silent
fallthrough to the next tier, so the default build falls through to the
native security-CLI path with no behavior change.

masterkey/gcoredump_darwin.go

@@ -1,4 +1,4 @@
-//go:build darwin
+//go:build darwin && keychain_gcore
 
 package masterkey
 

masterkey/gcoredump_stub_darwin.go

@@ -0,0 +1,17 @@
+//go:build darwin && !keychain_gcore
+
+package masterkey
+
+import (
+	"errors"
+
+	"github.com/moond4rk/keychainbreaker"
+)
+
+// DecryptKeychainRecords returns an error in default builds so GcoredumpRetriever
+// falls through silently to the next tier. The CVE-2025-24204 securityd-dump
+// implementation (gcoredump_darwin.go) is only compiled with -tags keychain_gcore,
+// keeping the default `go build` free of the exploit code and its byte signatures.
+func DecryptKeychainRecords() ([]keychainbreaker.GenericPassword, error) {
+	return nil, errors.New("keychain gcore dump not built in (rebuild with -tags keychain_gcore)")
+}