Feature: Configurable privacy controls for hook payload ingestion

## Summary

Add configurable ingest-time privacy controls that redact, hash, or drop sensitive data from Claude Code hook payloads before the dashboard persists events or broadcasts them over WebSocket.

## Problem / Opportunity

The dashboard captures rich tool inputs, tool outputs, transcripts, cwd values, prompts, and configuration-derived metadata. That detail is useful for debugging, but it can also include API keys, credentials, customer data, proprietary source snippets, or machine-specific paths. Today the project redacts secret-like keys in the Claude Config Explorer, but the live monitoring pipeline still stores event payloads largely as received.

A local-first monitor should let users decide what data is safe to retain without losing the observability value of sessions, agents, tool usage, tokens, costs, and workflow analytics.

## Proposed Feature

Introduce a privacy policy layer in the hook ingestion path with server-side rules that run before event persistence and WebSocket broadcast. Policies should support built-in detectors plus user-configurable allow/block/redaction rules, with a Settings UI that previews how sample payloads will be transformed.

## Scope

- Add a server-side redaction/sanitization module used by `/api/hooks/event`, import/reimport paths where practical, and any direct event persistence helpers.
- Support rule actions such as `mask`, `hash`, `drop_field`, `drop_event_payload`, and `preserve_metadata_only`.
- Include built-in detectors for secret-like keys, bearer tokens, common API key formats, private key blocks, email addresses, and absolute home-directory paths.
- Add persistent privacy settings with export/import behavior clearly documented.
- Surface per-event redaction metadata such as applied rule count and whether payload fields were dropped, without exposing the original values.
- Add a Settings panel with rule CRUD, enable/disable toggles, sample payload preview, and a conservative default policy.
- Ensure analytics, session lists, workflow charts, and cost calculations still work when event `data` has been partially redacted.

## Acceptance Criteria

- [ ] Hook events are transformed by the configured privacy policy before being written to SQLite or sent to WebSocket clients.
- [ ] Users can create, edit, disable, and delete redaction rules from Settings without editing server code.
- [ ] Built-in secret detectors catch common token/private-key patterns in nested event payloads and transcript-derived fields.
- [ ] Redacted events retain enough structured metadata for existing dashboards, filters, workflow analytics, and cost views to continue working.
- [ ] A preview endpoint shows before/after transformations for sample payloads without persisting the sample.
- [ ] Import/reimport behavior is explicit: either policies are applied consistently or the UI warns when historical records predate the active policy.
- [ ] Server tests cover nested objects, arrays, large payloads, hash stability, event dropping, WebSocket broadcast output, and fail-safe behavior when a rule is invalid.

## Non-Goals

- Full DLP classification or compliance certification.
- Encrypting the SQLite database at rest.
- Retrofitting every existing historical event automatically without a separate migration/rewrite workflow.
- Replacing the current Claude Config Explorer redaction behavior.

## Dependencies / Risks

- The hook path must remain fail-safe and non-blocking, so redaction errors should degrade to a conservative safe behavior and be observable.
- Over-aggressive rules could reduce debugging value; the UI should make policy effects visible before enabling broad drops.
- Import and live ingestion should not diverge silently, especially for users moving history between machines.

## Open Questions

- Should the default policy mask only obvious secrets, or also hash local filesystem paths by default?
- Should redaction metadata be queryable in the Events page as a filter/facet?
- Should there be a one-time historical rewrite job for users who enable privacy controls after already collecting data?