docs: document that l0_coefficient saturates, and warn when it has

[guptaishaan]

Addresses #719. Builds on #718 — that PR frees the JumpReLU threshold to move; this is about what happens once it can.

Note on the diff: this branch is stacked on #718, so it carries that PR's four commits as well. Only the last commit (docs: document that l0_coefficient saturates, and warn when it has) is new here. It needs #718 because on main the threshold is a read-only exp(log_threshold) property that barely moves, so the diagnostic below can't apply. Happy to rebase once #718 lands, or to retarget it if #718 changes shape.

#719 reports that l0_coefficient does nothing across 1/10/100. It isn't inert, it saturates. Sweeping downward, on cached activations with lr=3e-4, bandwidth 0.05, init threshold 0.01, 2000 steps:

l0_coefficient	0	1e-3	1e-2	0.1	1	10	100
final L0	478	364	124	36	26.6	26.4	26.0

The knob moves L0 10x over [1e-3, 1e-1] and is flat above ~1, so the values in the report were all past the point where it stops doing anything.

The threshold receives c * g_l0 + g_mse, and Adam fixes the step size at ~lr, so c only sets the direction of the update. Measured mid-training, the unit-c l0 gradient on the threshold is ~1000x the reconstruction gradient, so by c ≈ 0.01 the direction is already entirely the l0 term and further increases are no-ops.

Where that boundary sits depends on activation scale, jumprelu_bandwidth, d_sae, batch size and n_steps — at 20k steps instead of 2k the same sweep is still responsive at c=1 → 10. So a better default wouldn't fix it.

This PR doesn't change any optimization behaviour. It:

• documents the saturation, scoped to step mode — in tanh mode the penalty also back-propagates through W_enc/b_enc/W_dec and l0_coefficient responds normally (L0 3.84 → 2.59 → 0.84 across c = 1/10/100), so the "only gradient path is the threshold" reasoning doesn't apply there
• warns at the end of training when the threshold travelled ≥90% of what Adam permits, which is the signal that the run is in the saturated regime

On the sweep above the warning fires at c = 1 and 100 and stays quiet at 0.01 and 0.1, which is the intended split.

Implementation is a no-op TrainingSAE.training_convergence_warning() hook, so other architectures are unaffected. It's skipped when resuming from a checkpoint, since travel is measured from initialization.

Two things I deliberately left alone: the l0_coefficient=1.0 default (a behaviour change, and per the above no fixed value is right across setups), and the 5.0 in the tanh example, which isn't affected.

Happy to take this further — a target-L0 scheme is the option that would actually be robust to the scale-dependence — but that's a much larger change and a config-semantics decision, so I've kept this to documenting what the knob currently does.

Tests: 8 new, CPU-only, no model download. Existing suite passes.