feat(pii): export PII/audit events as a Prometheus counter

[walcz-de]

What

Adds a single Prometheus counter for the PII middleware / MITM audit pipeline:

localai_pii_events_total{kind, origin, action, direction}

Why

The PII EventStore ring buffer is capacity-bound and meant for recent-audit browsing via /api/pii/events. For operations you also want a monotonic, scrape-friendly signal on /metrics: how many detections/masks/blocks per hour, per origin — and most importantly whether the filter stopped firing after a deploy (silent-failure class; alertable with a simple rate()).

How

EventStore.Record is the single choke point every producer already goes through (request middleware, response scrubbing, MITM proxy connects/intercepts), so one lazily-initialised counter there covers all paths without touching any producer. Same lazy otel.Meter pattern as core/services/routing/billing, so the counter lands on the Prometheus-backed global MeterProvider installed by the monitoring service.

No behaviour change. Label cardinality is bounded — enum-like fields only (no pattern IDs, no user IDs).

Verification

go build ./core/services/routing/pii/ + go test ./core/services/routing/pii/... green. Deployed on a LocalAI instance with the PII middleware + MITM proxy active; counter series appear on /metrics after the first detection/connect event.

[walcz-de]

Live verification as promised: deployed this patch on our LocalAI instance (v4.5.6 + this commit, PII middleware active on cloud-proxy models). First request containing PII (name + email, masked before egress) produced:

localai_pii_events_total{action="mask",direction="in",kind="",origin="middleware"} 3

Counter lands on /metrics via the existing Prometheus-backed MeterProvider, series appears on first event, labels populate as designed (kind is empty for plain middleware detections — it's set for MITM proxy_connect events).