Re-identification table & key management

[AliakseiT]

Re-identification table & key management (deferred, detailed)

The pseudonymization boundary produces store-safe text plus reid_material
(Presidio encrypt items) and reads the AES key from an env var. The mechanism
is reversible; the management of the re-id secret and mapping is undefined.

Requirements

• Re-id table / key stays hospital-side, never in the engine store. Define the
  storage location and access control; enforce the invariant that reid_material
  and the key never touch runs/ or any engine-persisted artifact.
• Per-project keys (one key per intended-use project, not a global key).
• Key rotation + re-encryption strategy for retained pseudonymized corpora.
• Escrow / recovery policy for the re-id key (who can re-identify, under what
  authorization; audit log of re-identification events).
• Serialization of reid_material for durable hospital-side storage (Presidio
  OperatorResult items are in-memory today).
• Consider consistent pseudonyms across documents/elements for the same entity
  (longitudinal linkage) — currently each call is independent.

Verify

• Test that reid_material never appears in any store/ path (property test).
• Round-trip re-identification with a rotated key fails closed with a clear error.

Why deferred

This is a safety/governance design decision (key custody, authorization, audit),
not a mechanical build — it needs a deliberate policy, like the recall decision.