#18933: fix(security): use timingSafeEqual for pairing code comparison

## Summary Replace direct string comparison of pairing codes with `crypto.timingSafeEqual` to prevent timing side-channel attacks. ## Problem The pairing code lookup in `approveChannelPairingCode` uses `===` for comparison: ```ts String(r.code ?? '').toUpperCase() !== code ``` This is vulnerable to timing attacks — an attacker on the same network could measure response time differences to brute-force valid pairing codes during the approval window. ## Fix Zero-pad both buffers to `Math.max(a.length, b.length)` before calling `crypto.timingSafeEqual`, so: 1. Length-mismatched inputs **never short-circuit** before the constant-time comparison (no length-leak) 2. `timingSafeEqual` is **always called** regardless of input length 3. No HMAC overhead — avoids the entropy concerns raised in #19864 This approach was suggested by @arosstale in the #19864 review thread as the simplest correct fix. ## Changes - `src/pairing/pairing-store.ts` — zero-pad both buffers before `timingSafeEqual` in `approveChannelPairingCode` - `src/pairing/pairing-store.test.ts` — added spy assertion to confirm `timingSafeEqual` is called even for different-length inputs ## Relationship to #19864 That PR addressed `safeEqualSecret` (gateway auth tokens). This PR addresses the separate `approveChannelPairingCode` function, which does not use `safeEqualSecret`. Both functions had the same class of vulnerability.