CM-68943 Send ai-guardrails hook context with the scan so report-mode findings become violations - #504

… findings become violations

The scan now carries the hook's context inside the generic scan_parameters
metadata bag under an `ai_guardrails` key, which lets secret-detector attribute
the finding to the developer's device and, in report mode, promote it to a real
violation instead of a scan-scoped detection.

- `detection_source` is sent from `SECRETS_BLOCK_REASON_BY_EVENT_TYPE`, so the
  violation and the ai-security-manager hook event describe the same event with
  the same vocabulary. The three handlers now look the reason up through that
  map instead of hardcoding it, and `_ArgScanFeature` no longer carries a
  `block_reason` alongside its event type.
- `GuardrailsMode` replaces `InstallMode`: the same report/block pair describes
  both the installed mode and a single event's effective mode, which
  `get_effective_mode` now derives from the policy in one call.
- A generation id is minted per hook event when the IDE dialect does not supply
  one (Copilot), since it scopes the violation's identity.
- The device serial is cached in a temp file, keyed by username, so repeated
  hook invocations don't re-run the platform lookup.
- Copilot's sessionStart hook drops its timeoutSec.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…collection

The cache is now created 0600 via mkstemp and moved into place with os.replace,
so a concurrent hook can't read a half-written file and the write can't be
redirected by a symlink planted in the shared temp dir.

README gains an AI Guardrails section stating that scanning is server-side and
listing the device, user and environment data each event reports.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>