quota: per-namespace limits

Namespaces are a real tenancy boundary. Since m0017 they scope idempotency keys; tokens are
bound to a namespace at mint time and refused by a listener serving another; every Storage
method is namespace-scoped.

What a namespace has no way to express is a limit. There is no per-namespace cap on queue depth,
enqueue rate, concurrent executions, retained rows or storage footprint. One namespace can fill
the database and every other namespace on that server degrades with it — a noisy-neighbour
failure with no control surface.

Add per-namespace quotas:

• Depth — maximum pending jobs. Overflow reuses the existing on_excess machinery, so the
  behaviour is already defined: QueueError::QueueFull, whose Display is the cross-SDK wire,
  or a shed that returns Ok(true).
• Rate — enqueues per interval. The token-bucket work from the tier-3 scaling effort is the
  obvious mechanism rather than a new one.
• Concurrency — maximum in-flight executions, alongside the queue-level and per-task caps
  that already gate at dispatch.
• Retention — a row or byte ceiling that the retention machinery enforces.

Constraints:

• limits live where settings live, are readable and writable over the admin service (#836),
  and are enforced in the core, not in a shell — otherwise each SDK enforces them differently.
• enforcement gates at dispatch, consistent with the existing per-task limits. Never assert on
  execution timestamps alone.
• an unset quota means unlimited, and a quota that cannot be read must not fail open.

Start with the namespace-scoped Storage settings and the admin service work in #836, then trace the existing on_excess handling, dispatch gates, retention machinery, and tier-3 token-bucket work. Done means depth, rate, concurrency, and retention quotas are enforced in the core, unset quotas remain unlimited, and unreadable quotas fail closed without SDK-specific enforcement.