Hi team, I'm setting up dynamic_rate_limiter_v3 with priority reservation and have three short questions.

1. What happens when weights over-allocate? If priority_reservation sums to > 1.0, I understand named weights get auto-normalized. But since default_priority (default 0.5) is an independent pool and not part of that normalization, the effective total (named priorities + default pool) can exceed 100%.

My understanding is that this is fine because model capacity is always enforced at 100% via the model_saturation_check descriptor, so no real over-subscription happens — the pools just compete under that hard ceiling. Can you confirm this is the intended behavior?

2. Is default_priority: 0 + mandatory per-team priority the recommended pattern? There's an inconsistency I'd like clarified: the docs example uses default_priority: 0, while the code/README default is 0.5.

For production, is the recommendation to set default_priority: 0 and require every team/key to carry an explicit priority (so untagged traffic gets no reserved share under saturation), or is relying on the shared default pool the intended design (given spillover tests use default_priority = 0.25)? A note in the doc…