This is a comment left during a code review.
Path: docs/concepts/architecture-and-performance.md
Line: 233-236

Comment:
**"Ceiling ratchets up" claim is not supported by the implementation**

The tip states: *"If the probe succeeds, the ceiling ratchets up; if it triggers another 429, the ceiling lowers."*

Looking at `throttle_manager.py`, `rate_limit_ceiling` is only ever written in `release_rate_limited()`:

```python
if state.rate_limit_ceiling == 0:
    state.rate_limit_ceiling = prev_limit
else:
    state.rate_limit_ceiling = min(state.rate_limit_ceiling, prev_limit)
```

`release_success()` never touches `rate_limit_ceiling`. This means the stored ceiling can only decrease (or stay the same) — it never ratchets up as a result of a successful probe. When the system successfully operates at `ceiling × (1 + ceiling_overshoot)` requests, `rate_limit_ceiling` is unchanged; the soft ceiling returned by `_compute_soft_ceiling()` stays fixed too. If a new 429 fires at `prev_limit = ceiling × (1 + overshoot)` which is greater than the old ceiling, `min(old_ceiling, prev_limit)` still returns `old_ceiling` — no upward movement.

In practice this means a ceiling that was set too low (e.g. during a transient overload) can never self-heal upward; the system is permanently capped at `old_ceiling × (1 + overshoot)` regardless of how well the server performs afterward.

Additionally, "If the server rate-limits **again**, the controller records that level as a ceiling" is also inaccurate — the ceiling is set on the **first** 429 (via the `if state.rate_limit_ceiling == 0` branch), not only on subsequent ones.

How can I resolve this? If you propose a fix, please make it concise.