[bug] Fix process exiting with status 0 on collection failures (#11)

[p0dalirius]

Linked Issue

Closes #11

Root Cause

Every error branch in main.go's main() aborted with return after logging a warning. Returning from main yields exit code 0, so an unreachable DC, a bad credential, a failed LDAP query, a JSON serialization error, or a failed file write all looked like a clean run to any caller. Automated pipelines that relied on the exit status to gate downstream work would silently proceed on stale or missing output.

Fix Description

Replace return with os.Exit(1) in each of the seven error branches in main():

• credentials creation failure (L85)
• LDAP session creation failure (L100)
• LDAP connect failure (L105)
• LDAP query failure (L119)
• JSON serialization failure (L130)
• output file write failure (L135)
• the else branch where Connect() reports success == false without an error (L141)

The success path is untouched, so a normal run still falls off the bottom of main and exits 0. Adding os.Exit(1) to the final else branch fixes a pre-existing gap there where the program would also exit cleanly even when the LDAP connection reported failure without an explicit Go error.

How Verified

Runtime:

$ go build -o KeyCredentialHound .
$ ./KeyCredentialHound -dc 1.2.3.4 -u u -p p -d example.com --port 65535
[WARN] Error connecting to LDAP: ...
$ echo $?
1

Before the fix the same command exited with 0.

Test Coverage

None: the change is a control-flow swap from return to os.Exit(1) in seven well-isolated branches; there is no test harness in the repository, and the behavior is trivially verifiable from a shell.

Scope of Change

• Files changed: main.go
• Submodule pointer updated: no
• Behavioral changes outside the bug fix: none

Risk and Rollout

Existing scripts that explicitly ignore the exit status are unaffected. Scripts that previously assumed success because the exit code was always 0 will now see failures surface; this is the intended improvement.