feat(security): Zero-Trust Offline PII and Secret Pre-Flight Scanner

[ModernOps888]

Description

This PR addresses a fundamental Zero-Trust architecture gap within the pre-commit review flow. Currently, \git-lrc\ identifies leaked credentials by bundling the diff and sending it to an outbound LLM (via LiveReview or BYOK APIs). While the AI successfully catches the leak, this architecture ironically requires sending raw, unredacted corporate secrets over the internet to a third party.

To preserve the zero-trust nature of local, pre-commit hooks, this PR introduces a lightweight, robust Offline PII and Secret Pre-Flight Scanner.

How it works:

1. Implements local regex heuristics for high-entropy signatures (AWS Access Keys, GitHub PATs, Slack Tokens, RSA Private Keys) in \internal/appcore/secscan.go.
2. Intercepts the diff payload in \internal/appcore/review_runtime.go\ immediately after collection.
3. If a pattern match is detected locally, the network transmission is preemptively block-dropped, throwing a [FATAL] Local Security Check Failed\ directly to stderr and aborting the commit process safely offline.

Review Steps:

• Review the generic regex matching within the new \secscan.go\ file.
• Ensures compatibility with existing --skip\ flag for bypass during false-positive mock key commits.

Architected and developed as a collaborative improvement from a Principal Architect. 🚀

[shrsv]

Hello,

First of all -- thanks for your interest in git-lrc and effort in suggesting improvements to it.

I haven't gotten a chance to go in detail into the change yet, but a few high level thoughts:

1. We have had bugs/trouble with regex based scrubbing in the past, and easy to get wrong. From a cursory look, there seems to be regex dependencies on the client-side, which I am not greatly in favor of because updates, etc is in client control rather than our cloud -- where we can put in continuous improvements more easily.
2. About the Zero Trust part - we are trying to improve our security posture continuously -- but I am not sure we have used the label zero trust for our architecture (let me know if I have claimed otherwise anywhere else though). I do believe in transparency -- making code source available, get it inspected by as many people of various background and capabilities though. And trying to strike a good balance between out of the box usability and while providing good security guarantees.
3. We provide self-hosted/enterprise options for those who want to host the solution within their premises (cloud is not mandatory). But yes - there is an additional effort involved. In such a case - the solution wouldn't send the data over the network. Not to mention this data is under HTTPS/SSL, so it's not plain-text.

Either way -- just sharing my current thinking on security here. I will look into your contribution in more detail and figure out a way to use your inputs.

Thank you, again, for your interest and effort!