Fixes #980.

Problem

NamespaceResolver::resolve_prefix did a reverse linear scan of the entire
in-scope bindings stack on every call:

let mut iter = self.bindings.iter().rev();
...
(None, true) => match iter.find(|n| n.prefix_len == 0) { ... }
...
(Some(p), _) => match iter.find(|n| n.prefix(&self.buffer) == prefix) { ... }

bindings grows by one entry per xmlns[:prefix] declaration on every
currently open ancestor element, so its length tracks nesting depth. A
lookup that misses -- the common case for an unprefixed name with no
default namespace, or a genuinely undeclared prefix -- costs O(depth); doing
that once per event (NsReader::read_resolved_event* resolves every
Start/Empty/End) down a depth-D document costs O(D²). A ~1.3 MB
crafted document with one xmlns:* declaration per level (no huge tag, no
huge attribute count -- just ordinary depth) drives multi-second single-core
CPU stalls.

This is the same shape of problem as #969/#971 (check_for_duplicates
scanning every previously-seen attribute name), just over a different axis
(nesting depth vs. attribute count on one tag), as the issue calls out.

Root cause

NamespaceBindings are stored as a flat Vec acting as a stack: push
(via add) always appends, and pop (via set_level) always truncates
from the back when an element closes. There was no index from prefix to
position, so every lookup had no choice but to scan.

Fix

Small stacks (up to SMALL_BINDING_COUNT = 32 bindings) keep the direct
linear scan -- for a handful of in-scope bindings it's faster than hashing
and needs no allocation, which covers the overwhelming majority of real
documents. Once the stack grows past that threshold, resolve_prefix is
backed by a HashMap<Vec<u8>, Vec<usize>> index (prefix bytes, or an empty
key for the default namespace, to ascending stack positions), so a lookup
is O(1) average instead of O(depth).

Unlike the #971 fix (where the per-tag attribute list is thrown away and
rebuilt from scratch on every start tag), the namespace binding stack
persists and shrinks across the whole document, so the index needs
pop-side maintenance too, as the issue's "suggested direction" section
called out:

• add() (called by both the public API and push()) records each new
  binding into the index once it exists, seeding it from scratch (scanning
  every binding currently on the stack) the first time the threshold is
  crossed.
• set_level() (called by pop() and directly) removes exactly the
  entries it's about to truncate from the index before truncating
  bindings/buffer, using the fact that bindings only ever grows by
  appending or shrinks by truncating from the back -- so for every prefix,
  the positions being removed are exactly the trailing entries of that
  prefix's index list.

No new data structure conventions were introduced beyond what #971 already
established (HashMap gated behind a small/large threshold); no_std /
zero-alloc behavior for shallow documents is preserved since the index is
None (and never allocated) below the threshold.

One behavioral edge case is preserved exactly: an explicit empty prefix
(reachable via QName(b":local").prefix(), i.e. a malformed name like
:local) never resolves, because NamespaceBinding::prefix already
represents "no prefix" (the default namespace) the same way
(prefix_len == 0) internally, and the original code's
n.prefix(&buffer) == Some(Prefix(b"")) comparison could never be true.
This is covered by a dedicated regression test.

Verification

Benchmark (benches/issue980.rs, cargo bench --bench issue980),
resolving one element name per nesting level across a range of depths:

On unpatched master (via git stash of just src/name.rs):

Throughput drops ~70x over a 256x depth increase -- the O(depth²) signature
(each doubling of depth should roughly quarter throughput if the whole
document is O(depth²), matching the issue's own measurements).

With this fix, on the same range:

Throughput stays flat, confirming the fix.

Tests: two new regression tests in src/name.rs (resolve_prefix_past_index_threshold,
covering a hit near the bottom of a >32-deep stack, a hit at the top, a
miss, the default namespace, and -- the key regression check for pop-side
maintenance -- that popping back out of scope correctly un-resolves a
previously-found prefix without panicking or returning stale data; and
resolve_prefix_with_empty_prefix_never_resolves, covering the edge case
above both below and above the indexing threshold).

Ran locally and all pass:

• cargo test --all-features --benches --tests (1494 lib+doctest + all
  integration test binaries, 0 failures)
• cargo test --no-default-features
• cargo test --features serialize
• cargo test --features serialize,encoding
• cargo +1.79.0 check (pinned MSRV toolchain)
• cargo fmt -- --check
• cargo clippy --all-features --all-targets (no new warnings; the lib's
  only warning at HEAD, an unnecessary_unwrap in my first draft of
  set_level, is fixed in this PR's version)

Note

I'm the account submitting this PR (not the issue reporter); I read the
full issue thread, confirmed no other open/merged PR already addresses
this axis of the namespace resolver (only the sibling push-side fixes in
#970/#972/#974/#977/#979 exist, none of which touch resolve_prefix), and
independently confirmed the O(depth²) behavior with the benchmark above
before writing the fix.