JITSU-182: canonical row hashing — breaker survives serializer key reorder

[absorbb]

Follow-up to the config-keeper circuit breaker (#1476), from today's prod field experience. Linear: JITSU-182.

Why

Within hours of the breaker going live, #1478's deploy reordered JSON keys in every export row (zod parse emits schema keys first). Content was byte-for-byte identical after key normalization — but the breaker hashes raw row bytes, so it read 100% mass change and tripped fleet-wide on both replicas (correctly per its design, but the "serializer changes are rare" trade-off documented in the code did not survive day one). The breaker is currently disabled in prod pending this fix — all repos must survive field reorders.

What

• hashRows now hashes each row canonically: object keys sorted, ',' separator + length-prefixed keys (uniquely decodable — an encoding-collision construction from review is closed), type-tagged values, numbers by literal via json.Number (no float64 precision loss), decoder-normalized string escapes.
• Key-order changes at any nesting depth are invisible to the breaker; real value changes still trip. Number-literal formatting changes (1 vs 1.0) still trip by design — single stable producer, and that failure mode is a confirmation, not a miss.
• No baseline migration needed: seeding re-hashes the cached payload with the new function, so deploying this cannot itself trip — even onto a payload that byte-changed since the cache was written.
• The whole-payload lastRejected short-circuit deliberately stays byte-based (it only suppresses re-parsing of a byte-identical rejected generation).

Tests: reorder-immunity end-to-end (incl. clearing a held state with a reordered good payload), collision-resistance of the encoding (string/number/boundary/precision cases), escape normalization, literal sensitivity. 25 config-keeper tests green.

After deploy, re-enable with CFGKPR_BREAKER_ENABLED=true in jitsu-cloud-infra.

🤖 Generated with Claude Code

[jitsu-code-review]

Reviewed bulker/config-keeper/breaker.go and bulker/config-keeper/breaker_test.go for breaker correctness, regression risk, and failure-mode handling around canonical row hashing.

I did not find actionable bugs or security/correctness regressions in this change set. The canonical hashing approach appears deterministic and the added tests cover the key-order false-positive incident plus important value-distinction cases.