column masking policy: add observability metrics for lifecycle and runtime enforcement

## Background
Column masking policy is implemented, but we currently lack dedicated observability metrics. This makes it hard to answer operational questions such as:
- Is masking being actively applied in production?
- Are `RESTRICT ON` checks frequently blocking DML/CTAS?
- Are policy metadata loads/cache invalidations healthy after DDL?
- Are there regressions in latency/error rates related to masking path?

## Problem
Today we do not have first-class metrics to monitor masking lifecycle and runtime behavior. This creates blind spots for:
- incident triage
- performance analysis
- rollout safety checks
- compatibility validation (e.g. restore/reload paths)

## Proposal
Add a minimal but actionable metrics surface for column masking policy, including:

1. DDL lifecycle metrics
- create/alter/drop policy counts (success/failure)
- policy metadata cleanup counts on drop column/table

2. Runtime enforcement metrics
- masked result application count
- `RESTRICT ON` deny count by operation type (`INSERT_INTO_SELECT`, `UPDATE_SELECT`, `DELETE_SELECT`, `CTAS`)
- masking expression evaluation error count (if any fail-closed path is hit)

3. Metadata/cache metrics
- delayed policy load attempts/success/failure
- cache refresh/invalidation count after policy-related DDL

4. Optional latency histograms
- masking expression evaluation latency
- restrict-check decision latency

## Acceptance
- Metrics are exposed via existing TiDB metrics endpoint and visible in Grafana/monitoring pipeline.
- Metrics naming/labels follow existing TiDB conventions.
- At least one integration test validates key counters move as expected for basic lifecycle + restrict deny scenarios.

## Notes
This issue is about observability only, not changing masking semantics.