feat(pre-asap): unify dag_export's structural_hash with cse's (stage 3)

[zzylol]

Summary

Implements stage 3 of issue #223's 4-stage landing plan: dag_export's
structural_hash becomes literally the same function stage 1's
InternTable uses, instead of a parallel reimplementation.

• crates/types/src/pre_asap/cse.rs's structural_hash is now pub(crate)
  (was module-private), with its doc comment updated to describe the new
  cross-module caller instead of "unifying the two is stage 3, not done
  here."
• crates/types/src/dag_export.rs no longer has its own
  structural_hash(kind, detail, children, nodes) helper. push_node now
  takes the actual QueryExpr subtree each flattened DagNode represents
  and computes hash by calling pre_asap::cse::structural_hash(expr)
  directly — the exact same function call InternTable::intern makes for
  that same subtree during real CSE.
• New unit tests in dag_export.rs assert this literally, not just "hashes
  agree by coincidence": graph.nodes[root].hash == structural_hash(&root),
  and the same equality checked again at an interior node of a multi-level
  tree, not just the root.
• tools/dag-viewer/README.md's "shared subtree highlighting is a proxy"
  caveat is rewritten to describe the new, accurate state.

What's still a proxy, and why

tools/dag-viewer's "shared subtree" highlighting is not full real CSE
after this change, even though the hash it highlights on is now genuinely
the same hash share_common_subtrees's InternTable uses internally (not
a lookalike). Two independent reasons a hash match in the viewer still
isn't a guarantee of real sharing:

1. The PartialEq + legality gate isn't re-run. structural_hash is
   deliberately only a coarse bucketing filter — InternTable::intern
   always follows a hash match with a PartialEq check and a
   Schema::has_unique_key() legality gate before actually sharing an
   Rc. The viewer only has the hash, so e.g. an ungrouped Aggregate
   (no provable unique key, never actually hoistable) can still show up
   highlighted as "shared" there.
2. No real Rc identity crosses this tool's process boundaries. Each
   query given to the dag_export binary is lowered and exported
   independently (share_common_subtrees is never invoked in that path),
   and the viewer's own multi-file-load feature merges JSON produced by
   entirely separate dag_export invocations. There's no Rc<QueryExpr>
   for the viewer to compare pointer identity on — hash equality is the
   only signal available to it by construction, regardless of how well the
   hash itself is unified with the real pass.

I looked at closing this fully — threading real Rc::ptr_eq identity from
an in-process share_common_subtrees call through dag_export's
node-flattening into the exported JSON, plus having the dag_export binary
actually call share_common_subtrees across all queries given in one
invocation, plus a viewer highlighting-logic change to prefer that signal
over the hash when present. That's a reasonable follow-up, but it's a
materially bigger, separable change (new export API + binary change + JS
change) than a hash-unification stage should responsibly carry, and it
still couldn't help the viewer's primary "load several independently
generated JSON files" workflow (no shared process, so no shared Rc
regardless). Left as a future issue rather than folded into this PR.

Per the issue (#223 stage 4) and the task scope for this PR, cost_model.rs
and any CSE-credit/cost-based wiring are untouched — that remains blocked on
#237 and is being handled separately.

Test plan

• cargo build --workspace --all-targets
• cargo test --workspace (all green, including the existing 6 cse
  unit tests, the existing 3 crates/integration-tests/tests/cse.rs
  integration tests, and 2 new dag_export unit tests asserting hash
  parity with cse::structural_hash)
• cargo fmt --all -- --check
• cargo clippy --workspace --all-targets --all-features -- -D warnings

Part of #223.

🤖 Generated with Claude Code

[zzylol]

Rebased onto latest main (twice — #246 then #243 merged in the meantime) and addressed the tree-vs-DAG issue you flagged: structural_hash computed its coarse candidate-bucket hash by fully serde_json-serializing a node's whole subtree, called once per node in a bottom-up pass (InternTable::intern during CSE detection, dag_export::push_node during export) — a node near the root re-serializes everything below it, including descendants already hashed while processing an earlier node. O(subtree size) per node instead of O(1) amortized: quadratic-or-worse for a deep chain, worse still with real internal Rc sharing (which is exactly what this hash exists to detect).

Rewrote it to be memoized: each node's contribution is now its own tag + non-child scalar fields (still serde_json-based, safe for the f64s some fields carry — just O(own fields), not O(subtree)) combined with each Rc-backed child's hash, looked up in a new HashCache (keyed by Rc pointer) if already computed. InternTable now owns a persistent hash_cache across its whole lifetime — so a bottom-up pass hashes each node exactly once, O(N) total. dag_export::export threads the same cache through its own recursion for the identical reason.

This mirrors dag_node_count's fix from #243 (same underlying bug class — found while auditing other open PRs after that one landed), applied to hashing instead of counting.

New tests prove memoization doesn't change the answer, only the work: hashing a value gives the same result regardless of cache warmth; a tree with internal sharing hashes identically to an unshared-but-structurally-equal tree; and a direct proof that hashing a shared-branch BinaryOp populates the cache with exactly 2 entries (the shared branch's real node count), not more.

cargo build/test/fmt/clippy/doc all pass clean (453 tests, 0 failed; confirmed the pre-existing doc-link warnings don't fall within any changed code).