Canonicalise capture by type, so array order means something

[maverox]

Read these two facts before the diff

This does not close the reference run's 25 ordering differences, and it is not
meant to. Both structural, both checkable:

1. No Rust type survives to the ingress seam. The reply crosses it on both
   sides as bytes — RecordingBody<B: MessageBody> streaming chunks into
   capture_chunk(&[u8]) — because the order was serialised into them one frame
   upstream (services/api.rs:466, serde_json::to_string(&response)). A
   type-directed canon has nothing to read there, and the only thing that can be
   done to bytes is sort every array, which this change refuses to do (below).
2. The producers flatten before the boundary. card_network_pms_for_client
   (hyperswitch cards.rs:4155) does
   card_network_hashmap.keys().cloned().collect() into a Vec and pushes into
   a Vec; get_eligible_connectors' HashSet is collected into a
   serde_json::Value::Array one line before the call
   (superposition_sdk_config.rs:392). Both types say ORDERED at the boundary,
   and this change correctly leaves both alone.

What this covers, now that the hash seed is becoming a seam

Since this was opened, the plan for the class of nondeterminism behind those 25
has changed: the service will draw its hash seed once per correlation through a
recorded, substituted seam, so every collection a request builds iterates the
same way on replay as it did in the recording. That is the right fix for
reproducibility, and it takes reproducibility out of this change's job. This
change was first described as "canonicalise so the tape is reproducible"; that
sentence is no longer what it does. What it still does, in the order a reviewer
should weigh it:

It covers collections the seam structurally cannot reach. The seam is the
service's own hasher, installed through a centralised collection type and a
clippy disallowed-types gate — and both reach the service's workspace crates
only. A std::collections::HashSet inside a dependency's type — a generated
message type, a third-party client's response — that reaches a capture still
constructs with std::hash::RandomState, and nothing the service ships touches
it. The type_name check here is the only thing that sorts those, because it
reads the static type at every nested position regardless of which crate
declared it. The same holds for a dependency's HashMap under the router's
serde_json preserve_order build (see the second commit): only the map-key
sort here makes it canonical.

It represents a set as a set. A HashSet has no order by type. With a
reproducible hasher, its iteration order becomes a function of its insertion
sequence — so a refactor that builds the same set from a different source
order, a semantically empty change for a set, changes the tape and a strict
comparator flags an ordering difference on a type that has none. The canonical
sort here is what confines "an order difference means someone changed it" to
the collections whose order carries meaning. The seam makes order reproducible;
this makes it meaningful only where it is.

It makes tapes canonical across the transition. Recordings made before the
seam deploys carry sets in a canonical order already, and the comparator does
not have to know which side of the deployment a tape came from.

What changed

A collection unordered where it is built is serialised into a JSON array that
carries no record of whether its order ever meant anything. Rust seeds its hasher
per collection, so the same members come out in a different order between two
runs of the same image. Our answer so far (#99 → #102 → #104) was to stop
trusting array order in the comparator: it took the reference run from 26
blocking body differences to 1, and made an INTENDED ordering change invisible
in the same stroke.

Canonicalise at capture instead, while the type is still in hand.

Serde's data model does not carry the set/sequence distinction — HashSet and
Vec both call serialize_seq, which unlike serialize_struct has no type
name. But its collection calls are generic over the concrete type at each
position (serialize_field<T>, serialize_element<T>, serialize_value<T>,
serialize_some<T>), and std::any::type_name::<T>() needs no bounds. So a
Serializer producing serde_json::Value can read the static type of every
nested value at arbitrary depth, inside a #[derive(Serialize)] impl this crate
never sees.

Second commit — a map's keys are emitted in key order whatever
serde_json::Map does. The first commit inserted map entries straight into
serde_json::Map, which is sorted only when serde_json is built without
preserve_order. The router is not: josekit, thirtyfour and
ucs_common_utils enable serde_json/preserve_order transitively (verified
with cargo tree --no-default-features --features release --features v1 -e features -i serde_json at the workspace root), so in the binary this serializer
exists for, Map is an IndexMap that keeps insertion order — for a HashMap,
that process's hash order, written onto the tape as JSON key order. A map's
entries are now collected and emitted in key order; a struct's are not, because
field order is declaration order and deterministic on every run.

It is deliberately not "sort every array"

Sorting an array whose order carries meaning destroys that meaning rather than
preserving it: a removed sort on a ranked list sorts back to the same array —
invisible in the verdict AND unrecoverable from the tape, which is strictly worse
than the tolerance it replaces. The type check is what bounds the loss to
collections that had no order to lose, which is also what makes the sort
round-trip safe: such a collection deserialises the same from any order.

That refusal is enforced by the suite, not asserted in prose. Mutating the type
check to "always true" fails four tests.

Review notes

• Where it lives. deja-runtime, not deja: the recordable macro emits
  only ::deja_runtime:: paths and its integration test is in a crate that
  cannot see deja. deja re-exports it, so the vendor-facing surface is
  unchanged.
• A panic removed. recordable emitted json!({ "arg": &arg }), which
  expands to to_value(&arg).unwrap() — a serialisation failure in a delegated
  trait method took down the request. The recorder is invisible instrumentation
  and must never do that.
• Schema version 8 → 9. No field added or removed; what args and result
  HOLD changes, which is why it takes a version rather than a comment — Carry a correlation's recording decision on its span, and number fork buckets per callsite #100
  changed how fork ids were composed without touching a field and old and new
  tapes silently disagreed. A pre-v9 tape's arrays are in whatever order the
  recording process's hash seed produced. canonical_args_hash puts array
  elements in the key positionally, so a v9 candidate misses at every address
  rank against one (the scorer's args-free twin pairing still repairs it, but it
  is a miss). A pre-v9 recording is re-recorded rather than replayed — the
  same call made for Carry a correlation's recording decision on its span, and number fork buckets per callsite #100.
• Any strict array comparison must gate on the recording's
  event_schema_version >= 9. Not in this PR. The gate already has a source
  and no reader: the compactor collates it into
  SessionManifest.event_schema_versions (deja-compactor/src/lib.rs:282, via
  :1616 → :1739 → :1498) and git grep event_schema_versions crates/deja-orchestrator/src returns nothing.
• LookupKey::args_hash's doc said "order-independent" — true of object
  keys, false of array elements, on a field that sits on the key rather than
  inside Address and is therefore part of every rank. Corrected to say which
  half is which.

Verification

just verify exit 0, 811 passed (11 new across the two commits). cargo +1.85.0 check exit 0 on all five runtime crates. Every new test mutation-verified, and
the matrix checked for off-diagonal kills rather than assumed:

mutation	tests killed
type check → always false (normalisation off)	the 4 canonicalisation tests, and nothing else
type check → always true (blanket-sort)	a_sequence_keeps_its_order, ..._byte_identical, ..._round_trips_to_the_same_value, ..._canonicalised_at_its_own_depth
sort → sort + dedup	members_that_serialize_alike_are_both_kept, and nothing else
map-key sort → no-op	map_entries_are_emitted_in_key_order, and nothing else

members_that_serialize_alike_are_both_kept correctly survives the first
mutation — a two-member set of identical renderings reads the same sorted or not
— and falls only to the third. map_entries_are_emitted_in_key_order asserts on
the entry list the builder sorts, not on the finished Map, because on this
crate's BTreeMap build the finished map is sorted whether or not anyone sorted
it.

two_equal_sets_now_hash_to_one_lookup_key also asserts that the two
UNCANONICALISED captures moved the key, so a run whose hash seed happened to
produce the same order for both sets cannot pass while claiming the fix worked.

The fallback in to_value (a shape this serialiser cannot express degrades to
serde_json::to_value rather than to null) has no test that reaches it: no
shape serde_json accepts and this refuses could be constructed, because the key
rules were written to match. It is a safety net for a divergence not anticipated
here; a reachable one would be a bug to fix rather than to fall back from.