eqPtrs: see through array cells; linear pointer collection; correct the "tsorted" claim

[nanavati]

ICLazyArray elements are heap pointers hidden inside a value constructor (ArrayCell — see its comment in ISyntax.hs: elements are guaranteed to be references so that improveIf's equality check is a pointer comparison). That makes them invisible to expression-shaped traversals, and eqPtrs — the module-output CSE over heap defs — had two such blind spots:

hptrs (the internal tsort's edge function) emitted no edges from a residual PrimArrayDynSelect's array to its element cells, so the CSE fold could process a selection before its elements and the non-circularity check did not cover array-mediated references.
The CSE substitution did not canonicalize element pointers, so two selections over element-wise CSE-equal arrays never compared equal (cmpC compares arrays by ac_ptr) and always produced duplicate defs in the IModule.
Both get arms. The substitution arm affects only the comparison key, exactly like the existing IRefT arm: emission still goes through the caller's pointer-translation map, which already translates array cell pointers one by one (hToDef converts ICLazyArray to PrimBuildArray over translated refs), so a merge can never produce an inconsistent reference — it only redirects a duplicate def to its representative. The new tsort edges stay within the collected pointer set (collPtrs descends ArrayCells with the same reach), and an array-mediated reference cycle would already fail during normalization, so the edges cannot reject a previously-working design.

While touching hptrs, the quadratic Data.List.union folds are replaced with a single IntSet-backed collector. The collection deliberately preserves first-occurrence order: the tsort's output order is sensitive to edge order, the CSE fold's processing order follows it, and that decides — between duplicate defs — which pointer becomes the representative whose number appears in generated def names, which surface as signal names in the generated code. Preserving the order is essentially free (one extra membership test and one cons per pointer versus dumping the set sorted) and is a convenience, not a contract.

This is hygiene, not a user-visible bug fix. An A/B probe (two selections with the same index over separately-constructed, element-wise identical vectors, let-bound early and forced inside rules) shows exactly what the blindness costs and doesn't cost:

Before: the IModule carries two textually identical selection defs; after: one. The final Verilog is byte-identical either way — downstream CSE cleans the duplicate.
The same probe demonstrates that the defs list can order a selection def before its element defs (an HUnev cell allocated early, filled late) — harmless, because it turns out the emitted defs list is not in topological order for anyone and never has been: eqPtrs returns M.elems of the expression-keyed CSE map, i.e. canonicalized-expression order; the tsort's order is consumed only by the internal fold. The comment at the call site ("The pointers are returned in tsorted order") and the variable name tsorted_cse_ptrs promised otherwise; a follow-up commit corrects both so no future pass author builds on a dependencies-first assumption that does not hold.
Testing
Full testsuite on this branch: 18,501 PASS / 0 unexpected FAIL / 129 XFAIL (the only failures in the test environment are 20 SystemC tests without libsystemc and 3 permission-denied tests that cannot fail when run as root; identical to the unmodified baseline).
The def-name-sensitive directories (bsc.scheduler/urgency, bsc.verilog including the Mips sim, and all five bsc.arrays suites) pass with zero golden churn, confirming the order-preserving rewrite changes no generated output.
The A/B probe above: IModule def dumps and generated Verilog compared against unmodified main.
Split out as a standalone change because it is independent of any feature work: it was found while auditing heap-pointer-bearing value constructors (the ArrayCell pattern) for #1008, but nothing here depends on that PR.

🤖 Generated with Claude Code

https://claude.ai/code/session_01L1JGkCsP4oRfKg5bEJecVj

[quark17]

While there's no change in the Verilog, do we still want to have a test case that dumps an ISyntax stage and confirms that CSE happened early?

I'm not immediately understanding the comments in the code, so I'll have to come back and review this when I have time -- which might be an indication that the comments could be clearer or more concise. (The PR description was also a wall of text that was hard to decipher. To be able to quickly triage a PR, it would help to put the big picture up front in an intro: what's the motivation; is it user-visible, is it a bug fix, or is it just a clean-up; etc.)