Expose useful privacy metrics without leaking sensitive data

## Goal

Show users what Pentect protected and where warnings occurred, while keeping logs and metrics free of secret values and high-cardinality sensitive metadata.

## Metrics

- values masked by source: prompt, tool output, file, OCR, HTTP, and plugin;
- values restored by safe local boundary;
- blocked restoration attempts;
- unknown-format and inspection failures by safe reason;
- plugin timeout/failure counts;
- false-positive feedback events when explicitly submitted;
- client/version/platform health where it does not identify user content.

## Requirements

- Explain counts and detector labels in plain language.
- Preserve actionable reason codes in persistent logs.
- Batch writes to avoid per-token or per-chunk overhead.
- Avoid raw values, placeholders with stable cross-session identifiers, paths, URLs, request bodies, account IDs, and unbounded labels.
- Define retention and rotation.
- Allow local inspection without requiring telemetry.
- Make external telemetry opt-in and document its exact payload before implementation.
- Add tests proving synthetic secrets never appear in metric output.

No files, tests, or entry points are identified in the issue. Start by locating the existing logging and metrics paths, then define the safe reason codes, batching, retention, local inspection, and opt-in telemetry boundaries. Done means synthetic-secret tests prove metric output contains none of the prohibited sensitive data and the external payload is documented.

Written by the indexing model from the issue text.