fix(lint): spell the dedup key's NUL separator as a backslash-u-0000 escape, not a raw byte (#4763)

`check:nul-bytes` was red: `validate-null-guards.ts` carried a literal 0x00 at
byte offset 10987, inside the composite dedup key. Byte-identical at runtime --
this is purely how the character is spelled in source.

It is not cosmetic. A raw NUL makes grep/ripgrep classify the whole file as
binary and silently return ZERO matches, so the file drops out of code search
and out of every grep-based lint. git does not warn, because it only inspects
the first 8000 bytes to decide binary-ness and this one sits past that. A new
gate whose own source is invisible to code search is a bad way to start.

The unicode escape rather than the octal one, matching
`packages/rest/src/rest-server.ts:1065`: the octal form becomes a
legacy-escape error the moment a digit follows it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018iARDqtrhQgz6fVHDeDkbQ

Author: claude

packages/lint/src/validate-null-guards.ts

@@ -286,7 +286,15 @@ export function findUnguardedNullableOperands(
     if (!f) return;
     if (!opts.nullableFields.has(f.field)) return;
     if (guards.has(f.operand)) return;
-    const key = `${f.operand}${operator}`;
+    // NUL separates the composite key's two halves (it can appear in neither a
+    // field path nor an operator). Written as the `\u0000` ESCAPE, never as a raw
+    // byte: a raw NUL makes grep/ripgrep treat the whole file as binary and
+    // silently return ZERO matches, so the file drops out of code search and out
+    // of every grep-based lint - and git will not warn you, because it only
+    // inspects the first 8000 bytes to decide binary-ness. Same convention as
+    // `packages/rest/src/rest-server.ts`. `\u0000` rather than `\0`, which turns
+    // into a legacy-octal-escape error the moment a digit follows it.
+    const key = `${f.operand}\u0000${operator}`;
     if (seen.has(key)) return;
     seen.add(key);
     findings.push({