Identify multimap entries by (key, value) and drop the discriminator

[pathscale]

Companion to pathscale/WorkTablesIndex#13, which removes RandomMultiPair. Merge and publish that first; see the release cascade below.

Why

RandomMultiPair::insert scanned every entry sharing the key, because the value did not participate in the order and a stored entry could not be located by it. O(n) per insert, quadratic to fill one key.

A non-unique index that puts a whole generation under one key hits this directly. AgentCode measured, controlled A/B on one machine, same fixture, identical application code:

	beta.13	beta.14
one-file update	698 ms	15.10 s
put_symbols	138.5 ms	4.76 s
put_dependencies	112.9 ms	5.17 s
ensure_text_index	263.6 ms	4.96 s
marginal cost per row	9.04 us	330 us

arctic-wt 0.1.6 resolves under both and is not implicated.

What changed

MultiPair is now OrdMultiPair, identified and ordered by its (key, value) pair, so an entry is located by binary search and duplicate replacement falls out of the order.

The discriminator plumbing existed only to serve the random representation and is gone:

• MultiPairRecreate no longer takes a discriminator. A snapshot stores key and value, so reconstruction has nothing left to synthesise.
• reconstruct_multi_index_nodes no longer invents one per entry, which also removes the node-maxima collision it could produce on a damaged file.
• Pages are ordered by their minimum rather than their node id. A node id is a page maximum, and ordering by maximum puts a page that merely ends late ahead of one that starts earlier.

Two fixtures were rebuilt, and why

mixed_boundary_page_with_adversarial_link_order and multi_node_straddle_chain were built around a state only the random representation could produce: one page whose range sits inside another's. A (key, value) index partitions an ordered space, so a page maximum and its minimum agree on the ordering and that state is unrepresentable.

Both are rebuilt as valid partitions and keep the property that still has meaning: reconstruction does not depend on the order pages arrive in.

Format change

An index written by beta.14 or earlier must be reindexed, not loaded. Such a file orders entries within a key by discriminator, which is not (key, value) order. The checked-in .wt.idx goldens are regenerated in this commit, which is the visible evidence of it.

Release cascade

data_bucket pins WorkTablesIndex =0.0.8, so publishing 0.0.9 needs a data_bucket release before this can build against the published crate:

1. WorkTablesIndex 0.0.9 (Remove RandomMultiPair and make (key, value) the only entry identity WorkTablesIndex#13)
2. data_bucket, accepting 0.0.9
3. WorkTable beta.15 (this)

Tests

266 lib + 586 integration + 2 doc, all passing, verified against the index fix applied at 0.0.8 so data_bucket's pin still resolves and this change is isolated. Goldens are stable across repeated runs.

Related: size and eviction asks for beta.15 in #78.