[Enhancement]: Add worker-backed local-model providers for PII redaction

[afourniernv]

Affected area

PII redaction; dynamic plugins; worker protocol and SDKs; observability; documentation.

Problem or opportunity

Relay's deterministic PII recognizers cover structured identifiers but cannot identify contextual values such as names and addresses. The existing pii_redaction.local_model configuration reserves a model-backed lane, but its provider seam is process-global and in-process. Implementing Rampart as an unrelated sanitizer plugin would duplicate PII policy and bypass that first-party surface. Adding ONNX, tokenizer, model-cache, and model-download dependencies to the Relay host would also widen every host process.

Proposed enhancement

Extend pii_redaction.local_model so a manifest-backed grpc-v1 worker can provide local detector inference while the first-party PII plugin continues to own:

• supported LLM, tool, mark, and scope surfaces;
• provider codecs and content traversal;
• batching, payload bounds, timeout, and failure policy;
• detection offset validation and replacement behavior;
• composition with deterministic recognizers.

Add a language-neutral local-model provider registration to the worker protocol and Rust core registry. The provider implementation language is not part of the runtime contract: any process that implements the versioned grpc-v1 protobuf service can supply detections. Rust and Python receive maintained worker-author SDK helpers in the initial implementation; Node and other languages may implement the protobuf contract directly, and additional SDK helpers can be added without changing pii_redaction.local_model.

Rust, Python, and Node Relay hosts consume the same provider through Rust core and normal plugin configuration. No host binding embeds Python or depends on the Rampart implementation language.

Rampart is the first optional detector implementation to evaluate against this contract. It runs locally in an isolated worker process and remains disabled by default. The worker returns bounded detections only; it does not register independent Relay sanitizers or own redaction policy.

Runtime contract and binding impact

• The provider transport is the existing local grpc-v1 worker lifecycle, not a remote inference service.
• Requests and responses use versioned JSON envelopes over protobuf, so the contract is independent of the worker implementation language.
• The host installs providers before static component initialization and removes PII callbacks before provider deregistration and worker shutdown.
• Rust, Python, and Node hosts access the provider through the same Rust-core registry and lifecycle.
• Rust and Python receive maintained worker-author SDK APIs in the first slice.
• Node or another language can author a provider by implementing the protobuf service directly; a dedicated authoring SDK is an ergonomic follow-up, not a protocol requirement.

Alternatives considered

• Add Rampart directly to the built-in PII component: rejected because it puts ONNX and model acquisition in the host.
• Register Rampart as a separate sanitizer plugin: rejected because it duplicates PII policy and bypasses pii_redaction.local_model.
• Call a remote inference endpoint: rejected because network latency and data egress conflict with hot-path local sanitization.
• Use deterministic recognizers only: retained as the first lane, but insufficient for contextual PII.

Acceptance criteria

• A fake worker provider proves registration, invocation, timeout, failure, cancellation, and teardown before Rampart is added.
• The provider protocol is implementation-language-neutral and does not require Python in Relay hosts.
• pii_redaction.local_model batches bounded text inputs and rejects malformed, overlapping, out-of-range, or non-UTF-8-boundary detections.
• Real Relay lifecycle tests prove callback values are unchanged and only observability fields are sanitized.
• Rust and Python worker SDK tests cover the provider contract; Rust, Python, and Node host behavior remains compatible.
• A non-Python worker can implement the same contract directly from the protobuf definition without a PII-specific host change.
• Rampart quality, false positives, false negatives, latency, throughput, memory, overload, and recovery are measured separately from product runtime code.
• Deterministic and local-model PII profiles compose in a documented order.
• Packaging includes attribution and does not bundle model weights without explicit approval.
• Legal, distribution, supported-platform, quality-gate, and ownership decisions are explicit before first-party production support.

[afourniernv]

Closing this experiment in its current form. The example-level worker shape bypassed the existing pii_redaction.local_model provider seam. If we revisit Rampart, it should follow a generic worker-backed local-model provider contract owned by the first-party PII plugin, with the worker limited to detector inference.

[afourniernv]

Reopening. The implementation is continuing with the corrected shape: pii_redaction.local_model remains the first-party policy and sanitizer surface, and a manifest-backed gRPC worker supplies detector inference through a generic provider contract. The previous standalone example-plugin shape remains discarded.

[willkill07]

This should land after #546