fix!: apply competitor configuration whenever it is supplied

`Member::with_prior` and `with_drift_scale` were consumed only on the
branch that *creates* a competitor — `priors.remove` sat inside
`if !self.agents.contains(..)`. Supplying either for a key the history
already knew did nothing at all: no error, no warning, and output
computed from the default prior. A prior applied on a competitor's very
first event and was silently discarded ever after.

Configuration now applies whenever supplied. Two details this forced:

Configuration is tracked per *field* rather than as a merged `Rating`.
A member setting only `drift_scale` must not also assert the default
prior, or it would silently undo a prior seeded on an earlier event.

Slice state has to be refreshed. `drift_scale` is re-derived on every
forward pass, but a prior is written into the competitor's earliest
slice once, at ingestion, and `iteration` refreshes only slices after
the first. Without the refresh a late prior would reach the drift terms
and nothing else — a subtler version of the drop being fixed. This was
caught by a test, not by reading the code.

Conflicting values for one competitor within a single batch are now
`ConflictingCompetitorConfig` rather than resolved by iteration order.
Events in a batch are unordered, so "last one wins" would make the
result depend on traversal — and `tests/ingestion_equivalence.rs` exists
to rule exactly that out. Repeating the same value stays inert, which is
the shape callers get when configuration is a property of the domain.

That invariant turned out to be tested only for *unconfigured*
competitors: every helper in that file built members with `Member::new`.
Extended to cover configured ones, including a check that configuration
changes the fit at all, so the order tests cannot pass vacuously.

`with_prior` had no coverage under `tests/` whatsoever, which is how
this survived. Adds `tests/competitor_config.rs`.

`drift_scale_is_ignored_after_first_appearance` asserted the old
behaviour and now asserts the new one. It was written as a deliberate
change-detector — "moving the capture would be a visible break, not a
silent one" — so it inverted rather than being deleted.

Also removes `InferenceError::ConvergenceFailed` and `NegativePrecision`,
which no code path ever constructed: public variants advertising failure
modes no caller could observe. Partial #20 — its other items were
already resolved, except `Outcome::winner` still panicking.

BREAKING CHANGE: `prior` and `drift_scale` now take effect for
competitors the history already knows, where they were previously
ignored; a batch supplying conflicting values for one competitor is now
an error. `InferenceError::ConvergenceFailed` and
`InferenceError::NegativePrecision` are removed.

Closes #10. Refs #20.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011hcFjNDmHXZF8URGLku5zZ

src/error.rs

@@ -25,11 +25,6 @@ pub enum InferenceError {
     /// result has no representable likelihood. Configure a positive `p_draw`
     /// (via `HistoryBuilder::p_draw` or `GameOptions::p_draw`) to admit ties.
     TieWithoutDrawProbability { teams: (usize, usize) },
-    /// Convergence exceeded `max_iter` without falling below `epsilon`.
-    ConvergenceFailed {
-        last_step: (f64, f64),
-        iterations: usize,
-    },
     /// Inference produced a non-finite value (NaN or infinity).
     ///
     /// Indicates numerical breakdown; the resulting skills are meaningless
@@ -38,8 +33,19 @@ pub enum InferenceError {
         context: &'static str,
         step: (f64, f64),
     },
-    /// Negative precision: a Gaussian with `pi < 0` slipped into an API call.
-    NegativePrecision { pi: f64 },
+    /// One batch declared two different values for the same competitor's
+    /// configuration.
+    ///
+    /// `prior` and `drift_scale` configure a competitor, not an event, so a
+    /// batch that sets one of them twice with different values has no
+    /// well-defined meaning: events within a batch are not ordered, so
+    /// "last one wins" would make the result depend on iteration order.
+    /// Declaring the same value repeatedly is fine and is the expected shape
+    /// when a competitor's configuration is a property of the domain.
+    ConflictingCompetitorConfig {
+        competitor: usize,
+        field: &'static str,
+    },
     /// A prediction referenced a key the history has no skill for.
     ///
     /// Reported rather than skipped: dropping unknown keys turns a team of
@@ -96,18 +102,12 @@ impl fmt::Display for InferenceError {
             Self::InvalidParameter { name, value } => {
                 write!(f, "{name} is invalid: {value}")
             }
-            Self::ConvergenceFailed {
-                last_step,
-                iterations,
-            } => {
+            Self::ConflictingCompetitorConfig { competitor, field } => {
                 write!(
                     f,
-                    "convergence failed after {iterations} iterations; last step = {last_step:?}"
+                    "competitor {competitor}: this batch sets {field} to two different values"
                 )
             }
-            Self::NegativePrecision { pi } => {
-                write!(f, "precision must be non-negative; got {pi}")
-            }
             Self::UnknownKey { team, member } => {
                 write!(
                     f,