Ore convergence oracle

Throwaway. Its first job was to decide whether the content-anchored ordering of ore/doc/design/sequence_with_move.md converges, and it has done that; the results are in ore/doc/design/oracle_results.md. Its second was to decide what names a file, which is stage four and ore/doc/design/file_identity.md. Its third is to decide what a cross-file cycle should do, which is stage five and ore/doc/design/cycle_rule.md. Nothing here is meant to reach fe2o3_ore.

In memory only. No log, no serialisation, no files, no persistence, no run-length encoding. Applying an operation is set insertion; the whole of the derived state is recomputed from the operation set on every render, which is what design note section 2.7 licenses and what makes the implementation an obvious transcription of section 4 rather than an optimisation of it.

File	What it holds
src/id.rs	The three identifier spaces of section 4.1.
src/op.rs	Splice and Move, section 4.6.
src/doc.rs	Atoms, slots, the claim register, splitting, anchor resolution, cycle demotion, Fugue ordering, rendering.
src/replica.rs	The frontend: index-based intent to content-anchored operations.
src/cases.rs	Stage one, the adversarial cases.
src/stage2.rs	Stage two, randomised convergence over simulated replicas.
src/trace.rs	Stage three, the automerge-perf trace reader and coarsener.
src/repo.rs	The multi-file engine: three file-identity candidates in one renderer.
src/mrep.rs	The multi-file frontend.
src/mcases.rs	Stage four, the file-identity cases, predictions written first.
src/mstage.rs	Stage four, randomised multi-file convergence.
src/cyc.rs	Stage five, the cross-file cycle cases, predictions written first.
src/csweep.rs	Stage five, the sweep that plants cycles on purpose.

Two axes are selectable and both matter to the results:

• Mode -- ClaimRegister (design note section 4.4), SplitBeforeMove (field note section 4.3, arbitrated), SplitBeforeMoveNaive (the same unarbitrated, kept to show that it duplicates).
• Bind -- LeftBias (the design note as written) or Successor (the repair).

Stage four adds a third axis, Identity, and fixes the other two at ClaimRegister and Successor, those being the only ones the design note now specifies.

• Derived -- candidate B. No file field on a content operation; each file's creation mints an origin anchor, a one-byte atom born dead, and a file is the subtree beneath one.
• Recorded -- candidate A. file: FileId on content operations, one Fugue tree per file, one repository-global claim register.
• RecordedLocal -- candidate A with the per-file claim register fe2o3_ore has today. Kept to measure what the status quo does with a cross-file move.

Stage five adds a fourth axis, CycleRule, meaningful only under Derived, being what the renderer does with a cycle in the anchor graph that runs between two files. Demote is design note section 5.4 unchanged; ConfineVictim, ConfineCycle, LowestEdge and WholeCycle are the four candidates of cycle_rule.md. Predictions for every case were written before the engine could run any of them, in PREDICTIONS_cycle_rule.md.

Running

export CARGO_TARGET_DIR=~/.cache/cargo-targets/ore_oracle_target
cargo test  --release
cargo run   --release --bin stage1
cargo run   --release --bin stage2 200
curl -sLo data/editing-trace.js \
  https://raw.githubusercontent.com/automerge/automerge-perf/master/edit-by-index/editing-trace.js
cargo run   --release --bin stage3 data/editing-trace.js
cargo run   --release --bin stage3 data/editing-trace.js --fine
cargo run   --release --bin stage4
cargo run   --release --bin stage5 400
cargo run   --release --bin stage6
cargo run   --release --bin stage7 100
cargo run   --release --bin stage8 4000

data/ is not committed. The trace is CC-BY from automerge/automerge-perf.