service: per-service budgets (rate, concurrency, tokens) are not enforced #1132

ServiceConfig has no budget field and nothing enforces one. A service accepts requests as fast as a channel delivers them, creating sessions and spending tokens without limit.

This matters more than the other gaps because service input is third-party by assumption. The design record already states the requirement — "budgets must be enforced per service so one noisy service cannot starve the fleet or the wallet" — and spec 0170 lists per-service budgets as explicitly not implemented while describing service sessions as least-privilege. Capability confinement shipped; resource confinement did not.

Scope to decide:

• Rate — requests per interval per service, and whether per channel or aggregate.
• Concurrency — simultaneous in-flight turns; the natural backstop against a webhook storm.
• Tokens — per request, per session, or per window, and what happens at the ceiling (refuse, queue, degrade).

Rejections need to be visible to the caller (a distinct status, not a timeout) and to the operator. Note this interacts with #1133 — a budget you cannot observe being approached is hard to set correctly.

Per spec 0173's structural guarantee, any scalar added to ServiceConfig is read at use, so a budget field applies on the next request without additional plumbing.