Idempotency fingerprint depends on header key ordering

A false idempotency conflict (409 idempotency_key_reused) for a request that is, semantically, identical to the original is a hard failure a client cannot self-heal from by retrying -- retrying with the same key just gets the same 409 again. If the set of headers folded into the fingerprint ever arrives in a different order across two calls that are otherwise the same request (a very real possibility once headers are collected from a map anywhere upstream -- Go deliberately randomizes map iteration order), a legitimate retry gets permanently rejected instead of replayed, and the caller has no recovery path except picking a brand-new Idempotency-Key, defeating the entire point of supplying one.

Fingerprint's doc comment states: "Header values are sorted by key name so header map iteration order never affects the result." The function no longer actually sorts the header keys before hashing them.

h := http.Header{"X-Tenant": {"acme"}, "X-Region": {"us-east"}} a := idempotency.Fingerprint("POST", "/v1/charges", []byte({}), h, []string{"X-Tenant", "X-Region"}) b := idempotency.Fingerprint("POST", "/v1/charges", []byte({}), h, []string{"X-Region", "X-Tenant"}) fmt.Println(a == b) // got: false, want: true

This is a "same input, different output" determinism bug in a function whose entire job is producing a stable identity for a request. Any caller composing the headerKeys slice dynamically (e.g. from a config map, or a per-tenant list of "headers that matter for this endpoint") is exposed the moment that composition doesn't happen to produce the same order every time.

The doc comment already describes the intended behavior ("sorted by key name"). Compare it against what the function's key-processing loop actually does before hashing each header -- something that used to make that guarantee true is missing.