perf: reduce large-document binary Ion 1.0 read costs on the Element and AnyEncoding paths

[hsbakshi]

Summary

This PR reduces read costs for large (~10–30 KB) binary Ion 1.0 documents
on the Element/DOM path (the API that parses a whole document into an
in-memory tree) and the lazy AnyEncoding path (the reader mode that
auto-detects text vs binary), and adds a large-document benchmark
covering them. The optimizations are independent: reserving
symbol-table capacity when applying a local symbol table, an FxHashMap
field-name index on Struct, and an inlining/variant-ordering pass over
the AnyEncoding dispatch layer. On value-heavy documents,
Element::read_one improves 10–13% on the criterion benchmark (7–8%
under an independent profiling harness; both aarch64), Struct::get by
name improves
30–37%, and the lazy AnyEncoding reader improves 9–12%. No public API
changes. Follows discussion in #1038.

Motivation

Large documents spend their time in different places than small ones.
Profiling large binary Ion 1.0 documents (value-heavy and symbol-heavy
flavors at ~10 KB and ~30 KB, one reader per document) shows:

• On a ~30 KB value-heavy document, Element::read_one costs ~3.8x
  the concrete lazy reader (v1_0::Binary) reading the same bytes.
• The AnyEncoding layer adds +48–49% over v1_0::Binary on
  value-heavy documents at both sizes. The gap grows with document size,
  so large documents do not amortize it away.
• Building Struct's by-name field index shows ~12% of
  Element-path profile samples inside SipHash hashing frames (SipHash
  is the DoS-resistant hasher Rust's HashMap uses by default).
• Local symbol table (LST) processing allocates per symbol with no
  capacity reservation, so symbol-heavy documents pay repeated map/vec
  growth.

The existing benchmark suite has no large-document
one-reader-per-document case and no by-name field lookup case, so none of
these paths had a regression guard.

What changed

• b6cfb07 perf: add large-document read benchmark: new
  benches/large_doc_read.rs. Value-heavy and symbol-heavy documents at
  ~10 KB and ~30 KB; Element::read_one (default features); lazy
  AnyEncoding and v1_0::Binary readers (feature-gated like the
  existing benches); and a Struct::get by-name lookup flavor that
  includes ~13–17% miss lookups, so both hit and miss paths are guarded.
• 6d6e61f perf: reserve symbol table capacity when applying a local
  symbol table: reserves capacity up front from the parsed
  pending-symbol count at LST-apply time. (The count is only known after
  parsing: the binary symbols-list length prefix is in bytes, not
  elements.) Removes growth-reallocation churn on symbol-heavy documents.
• 4f0bcfd perf: use FxHashMap for Struct's by-name field index:
  swaps the index HashMap to FxHashMap (a much faster hasher that is
  not DoS-resistant). Rationale: field names are the same untrusted-input
  class as symbol text, and the existing ids_by_text index in
  symbol_table.rs already uses FxHashMap for that. The exposure
  profiles do differ: the symbol table precedent is per-stream and
  transient, while Struct is a retained DOM value; that difference is
  part of why the commit is severable. The hasher does not appear in any
  public signature. Struct's Debug output changes: the field-name
  index is no longer printed (it is derived data with arbitrary map
  ordering). Note for maintainers: if you prefer
  DoS-resistant default hashing on DOM types (the serde_json::Map
  convention), we're happy to drop this commit; it's severable.
• 3a20f19 perf: inline AnyEncoding delegation and reorder hot
  dispatch enums: adds #[inline] to ~150 small AnyEncoding
  conversion/delegation functions, letting the compiler eliminate call
  overhead in this thin wrapper layer, and declares the Binary_1_0
  variants first in three internal-dispatch enums so the hot variant is
  matched first. Source-compatible: the three enums derive only
  Debug/Copy/Clone, with no Ord, no explicit repr, and no
  discriminant reads (verified). Debug::fmt and the expect_* error-path functions
  were deliberately excluded from inlining. The annotations were
  measured in aggregate via the new benchmark, not individually; the win
  survived the trim in the review commit (−10 to −13% re-measured).
• ea09fc7 review polish: naming, comments, and bench cleanup from
  self-review.
• bd3eb06 refactor: apply local review feedback: trims the
  #[inline] set to small dispatch/From shims and documents that
  convention at the module level; comment corrections; the capacity
  reservation now counts only symbols that enter the text index.

Benchmarks

Median of 3 interleaved before/after runs (aarch64, release; baseline =
main plus the new benchmark commit; x86_64 run to follow before merge;
see caveat below). Values shown as 10 KB / 30 KB:

Case	10 KB	30 KB
element_read_one (value-heavy)	−10.4%	−13.5%
struct_get_by_name (incl. miss lookups)	−30%	−37%
lazy_any_read_all (value-heavy)	−8.9%	−11.7%
lazy_binary_1_0 (value-heavy)	±0	±0
lazy_binary_1_0 (symbol-heavy)	−6.4%	−9.1%

The concrete v1_0::Binary value-heavy case is unchanged, as expected:
none of the three optimizations touches that path. Its symbol-heavy
improvement comes from the capacity reservation, which runs on every
path.

Existing suite, before/after: read_many_structs and
encoding_primitives, 35 cases total, no sustained change >2%.

We also cross-checked the results with a second, independent profiler
(dial9-tokio-telemetry,
perf-based CPU sampling). By-name lookups reproduced at −42 to −44%, with
the baseline SipHash frames disappearing from the profile entirely.
Element::read_one reproduced directionally at −7 to −8% under that
profiler's harness. Output checksums were identical between baseline and
patched builds on every run.

Severability

The three optimizations are independent: each commit stands alone,
individually measurable and individually revertable. Happy to split any
of them out (in particular the FxHashMap commit, per the hashing note
above) or reshape scope on request.

Relationship to the small-document PR

Complements our small-document fixed-cost PR (#1039). That PR targets per-document setup costs
(reader construction, IVM/LST processing); this one targets the
value-scanning and DOM costs that dominate on large documents. The
branches are independent; either can merge first. Both PRs touch
symbol_table.rs and apply_pending_context_changes in adjacent hunks,
so whichever lands second expects a small manual rebase; the bench
helper duplicated between the two will be consolidated by whichever
lands second.

Test plan

• cargo test --workspace --all-features: 15,003 tests pass.
• cargo clippy --workspace --all-features -- -D warnings and
  cargo fmt --check: clean.
• No public API changes.

Caveat

All numbers above are aarch64. An x86_64 before/after run will be posted
on this PR before it's ready for merge.

By submitting this pull request, I confirm that my contribution is made
under the terms of the Apache 2.0 license.