docs: state what the joint's cost actually scales in

A consumer measured an 8x difference in solve time between two fits over
the same events, the same slices and the same ~2,000 nodes:

  career fit   (gamma = 0)      787 ms
  drifting fit (gamma = 0.15)  6214 ms

Entirely the collapse rule. A competitor with zero drift contributes one
variable however long the history, so a drift-free fit's joint is smaller
than a drifting one's by roughly the slice count — and to factorise, by
its cube. Choosing a drift configuration is therefore also choosing a
query cost, and nothing said so.

Documented on `Joint`, on `Joint::variables` and on `posterior_of`, with
the measurement. `variables()` is named as the number that decides
affordability, since it can be read before committing to a batch.

Also states the thing the consumer proposed as a future optimisation,
because it is already true: an absence is not an appearance, so a
competitor seen in the first and last of a hundred slices contributes two
variables rather than a hundred. The matrix is already as small as the
model allows on that axis.

tests/joint_handle.rs pins the mechanism — ten slices, two competitors,
twenty variables drifting against two at `gamma = 0` — so a change to the
collapse rule cannot quietly remove the property the docs now promise.

Refs #51

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

src/history.rs

@@ -1109,6 +1109,14 @@ impl<T: Time, D: Drift<T>, O: Observer<T>, K: Eq + Hash + Clone> History<T, D, O
     /// [`Joint`] with [`History::joint`] instead — the answers are identical,
     /// and only the first one pays.
     ///
+    /// # Cost
+    ///
+    /// A dense solve over the history's *appearances*, not its competitors. A
+    /// drift-free competitor collapses to a single variable however long the
+    /// history, so the same events can differ enormously in cost depending on
+    /// the drift configuration — see [`Joint`], which also amortises this
+    /// across many questions.
+    ///
     /// # Limitations
     ///
     /// Exact only for a history whose events are all scored, because a scored
@@ -2205,6 +2213,34 @@ impl<T: Time, D: Drift<T>, O: Observer<T>, K: Eq + Hash + Clone> History<T, D, O
 /// added while it is alive. That is what makes it correct without any
 /// invalidation logic: there is no window in which the factorisation could
 /// describe a fit that no longer exists.
+///
+/// # What the cost actually scales in
+///
+/// Not competitors, and not slices times competitors. One variable per
+/// *appearance* — a competitor per slice they appear in — minus every
+/// consecutive pair with no drift between them, which collapse to a single
+/// latent variable.
+///
+/// That last clause dominates, and it is not obvious. A competitor whose drift
+/// is zero contributes **one** variable however long the history: whole-history
+/// `gamma = 0`, or `drift_scale = 0` on that competitor. So two fits over the
+/// same events and the same slices can differ in problem size by roughly the
+/// slice count, and in factorisation time by its cube. Measured by a consumer
+/// on a ~2,000-node model over 76 slices:
+///
+/// ```text
+/// career fit   (gamma = 0)      787 ms per solve
+/// drifting fit (gamma = 0.15)  6214 ms per solve
+/// ```
+///
+/// Choosing between a drifting and a drift-free configuration is therefore also
+/// choosing an 8x difference in query cost. [`Joint::variables`] reports the
+/// number that decides it, and can be read before committing to a batch of
+/// queries.
+///
+/// Slices a competitor sits out cost nothing: an absence is not an appearance,
+/// so a competitor seen in the first and last of a hundred slices contributes
+/// two variables, not a hundred.
 pub struct Joint<'h, T: Time, D: Drift<T>, O: Observer<T>, K: Eq + Hash + Clone> {
     history: &'h History<T, D, O, K>,
     cholesky: crate::joint::Cholesky,
@@ -2232,9 +2268,14 @@ impl<T: Time, D: Drift<T>, O: Observer<T>, K: Eq + Hash + Clone> Joint<'_, T, D,
     /// Number of variables in the joint: the history's appearances, after
     /// collapsing consecutive pairs a competitor does not drift between.
     ///
-    /// This is what the cost scales in, and it is not the competitor count — a
-    /// competitor contributes one variable per slice it appears in. Worth
-    /// checking before asking for a joint over a long history.
+    /// This is what the cost scales in — `O(n^3)` to factorise, `O(n^2)` per
+    /// query — and it is neither the competitor count nor slices times
+    /// competitors. A drift-free competitor contributes one variable however
+    /// many slices they appear in; see the type docs for how large that
+    /// difference gets.
+    ///
+    /// Worth reading before committing to a batch of queries: it is the one
+    /// number that says whether a joint over this history is affordable.
     #[must_use]
     pub fn variables(&self) -> usize {
         self.width