Escape the NUL separators in PolicyEnforcer's log dedup key

[thjaeckle]

What

PolicyEnforcer.java carries two raw NUL (U+0000) bytes on the dedupKey line in
missingReferenceLogger -- written as literal control characters instead of unicode escapes.
This replaces each with the six-character escape \u0000.

-final String dedupKey = policyIdStr + "<raw NUL byte>" + referencingEntry.getLabel() + "<raw NUL byte>" + target;
+final String dedupKey = policyIdStr + "\u0000" + referencingEntry.getLabel() + "\u0000" + target;

Why

NUL is a perfectly good separator here -- it cannot collide with a policy id, entry label or
entry reference. The problem is only that it was written as a raw byte, which makes the whole
file binary to any tool that scans for NUL.

The practical damage is silent search failure:

$ grep -n 'defaultEvaluator' PolicyEnforcer.java
$          # <- nothing, for a 650-line Java file with 8 matches

grep classifies a file containing NUL as binary and suppresses matches. No error, no
diagnostic -- it reads exactly like "no matches". ripgrep is only marginally better,
reporting binary file matches (found "\0" byte around offset 8340) instead of the
matching lines.

I hit this while reviewing an unrelated change to this file and initially mistook it for a
broken tool.

Why it went unnoticed

Git's binary heuristic only inspects the first 8000 bytes of a file. These NULs sit at
roughly offset 8340 -- just past the window. So git diff, git blame and the GitHub web
view all render the file as ordinary text, while grep silently ignores it. Introduced in
3ab05665e8 (2026-04-30).

Behaviour

Unchanged, verified at the artifact level. Unicode escapes are resolved by the Java lexer,
so the string literal still contains exactly one NUL character. Compiling the module before and
after the change produces byte-for-byte identical class files -- checked with cmp for
PolicyEnforcer.class and all five sibling classes in the package.

No new test: there is no behavioural delta to pin, and a test asserting "this source file
contains no NUL bytes" would be testing the toolchain rather than the code.

Scope

I scanned every git-tracked text file in the repository (.java, .conf, .yml, .xml,
.md, .tpl, .sh, .json, .properties, .js, .ts, .html, .css) for NUL bytes --
this was the only affected file.

policies/enforcement 278 tests green, mvn license:check clean.

[hu-ahmed]

LGTM!