relayer: clarify or canonicalize list ordering in request content hashes

[ming1523]

Describe the issue

The relayer request content hashing for public_decrypt, user_decrypt, and delegated_user_decrypt appears to be order-sensitive for list fields, even though the implementation itself already contains TODOs suggesting canonical ordering should be considered.

Relevant files:

• relayer/src/core/public_decrypt_request.rs
• relayer/src/core/user_decrypt_request.rs

Both files currently hash list items in their incoming order, for example:

• ct_handles
• contract_addresses
• ct_handle_contract_pairs

At the same time, the relayer tests document deduplication semantics in terms of "identical content should return the same job_id".

Context

There are TODO comments in the content hash implementations:

• TODO: Consider canonical ordering for list items.

This suggests the current behavior may be incomplete or at least not fully settled.

The concern is that two requests that are semantically equivalent but serialized with a different list order can produce different content hashes and therefore different deduplication behavior / job IDs.

Steps to Reproduce or Propose

Potential reproduction path:

1. Submit a public_decrypt request with handles [A, B]
2. Submit the same request with handles [B, A]
3. Observe whether the relayer returns different job_ids

Similarly for user_decrypt / delegated_user_decrypt:

1. Submit a request with the same logical contract_addresses / ct_handle_contract_pairs but different ordering
2. Observe whether deduplication treats them as different requests

Question

Should these list fields be treated as order-sensitive protocol inputs, or should the relayer canonicalize them before hashing for deduplication?

If ordering is intended to be semantically significant, it may be worth documenting that explicitly in the API docs.
If ordering is not intended to matter, canonicalization plus tests would likely make the deduplication behavior more intuitive.