Wire human review for audit entries

[martsokha]

Status

Open — the ontology ships ReviewDecision / ReviewStatus and an Option<ReviewDecision> field on every AuditEntry<M> (see `crates/nvisy-ontology/src/provenance/{review,entry}.rs`), but no producer in the workspace ever sets it. The fields ride along on every persisted audit envelope as `null`.

Context

The data model is in place for a human-in-the-loop review step: a reviewer inspects a pending or applied redaction, records approve/reject/escalate, and the decision flows downstream alongside the audit entry. The wiring (who calls it, when, where the decision comes from) has never been built.

What this issue becomes

A real review path:

• An ingress point — likely a server route (`POST /audits/:id/entries/:entity_id/review`) — that takes a `ReviewDecision` payload and writes it onto the matching `EntityRecord::audit` entry.
• A persistence rule — does the review mutation re-write the audit envelope in place, or append an event? The simpler model is in-place mutation since `AuditEntry::review` is already optional.
• A consumer that actually reads the decision: redaction re-evaluation, validator behaviour change on `Rejected`, alerting / SLA tracking against `Pending`. Without a consumer the decision is decorative.

Triggers to revisit

• A customer needs reviewable redactions (most regulated-data flows eventually want this).
• We add an `Action::Review` strategy that opts an entity into the review queue at evaluation time.

Scope when implemented

• Server route + auth gate
• Registry mutation API to set a record's review decision
• Decide on validator / re-evaluation behaviour for each `ReviewStatus`
• Audit log entry for the review action itself (who reviewed, when, with what evidence)