Audit: does DashMap/HashMap iteration order in the splice-junction path reach any output?

[BenjaminDEMAILLE]

Not a new dependency: a question about the semantics of one we already have.

Observation

src/junction/sj_output.rs stores splice-junction counts in a DashMap<SjKey, SjCounts> and
exposes iter() (:342). filter_novel_junctions (src/junction/mod.rs:166-233) consumes that
iterator and .collect()s into a Vec<(NovelJunctionKey, JunctionInfo)>. A DashMap iteration
visits shards in an order that depends on hashing and on concurrent insertion, so the order of
that Vec is not guaranteed stable across runs or thread counts.

Downstream, insert_novel (:145) inserts each entry into a HashMap<JunctionKey, JunctionInfo>,
which is order-insensitive for the map's contents. So the question is not whether the map ends up
the same, it is whether anything downstream ever observes an order derived from either of those
containers: two-pass SJ insertion into the genome/SA, SJ.out.tab emission, or any numbering /
indexing assigned in traversal order.

This may well be clean already. It should be verified and then locked, rather than left as an
assumption, because it is precisely the class of bug that reproduces only under load and only on
some machines.

Checklist

• Trace every consumer of SpliceJunctionStats::iter() and of the HashMap in
  SpliceJunctionDb to the point where an order could become observable
• If an order does escape: sort on an explicit total key (chr, start, end, strand) at the
  boundary, not deeper
• Add a test running two-pass mode at two different thread counts and comparing the SJ outputs
  and the resulting index bytes
• Same audit for any other HashMap/DashMap whose iteration reaches output