fix: stop EscapeDN and PostalAddress.Escape corrupting invalid UTF-8

[netliomax25-code]

1. EscapeDN and PostalAddress.Escape walk their input with a rune range loop, so a byte that is not part of a valid UTF-8 sequence ranges as utf8.RuneError and is written back as U+FFFD.
2. The escaping is then not injective: EscapeDN("\xeb") and EscapeDN("\xef\xbf\xbd") return the same string, so two different values an application escapes into a bind or search DN collide onto one DN, and non-UTF-8 input (e.g. latin-1 text) is silently corrupted instead of escaped.

EscapeDN now emits the RFC 4514 section 2.4 hex pair for such a byte (\eb), which ParseDN already decodes back to the original octet. PostalAddress.Escape iterates bytes instead, since RFC 4517 defines no general hex escape there and ParsePostalAddress reads bytes, so every octet round-trips. Escaping of valid UTF-8 input is unchanged. Found with a fuzzer asserting that escape-then-parse returns the original value; regression tests added for both helpers.

This fix was found and prepared with AI assistance and reviewed by me before submitting.