feat(service): Add concurrency limit to StorageService

[jan-auer]

Builds on #322 (task spawning with panic isolation).

Adds a semaphore-based concurrency limit to StorageService that caps the total number of in-flight backend operations. When the limit is reached, new operations are rejected immediately with HTTP 429 rather than queueing, preventing backend overload during traffic bursts.

The limit is acquired before spawning each operation task and the permit is held until the task completes (including after panics). Configured via service.max_concurrency (default: 500, effectively unlimited without configuration).

Includes tests for rejection at capacity and permit release after panics.

Next steps

• Web request concurrency limit: Add a high web-tier limit (middleware, 503 on exhaustion) that protects against connection floods, composing with the existing InFlightRequestsLayer. Excludes health/ready endpoints.
• Bounded task queue: Replace direct tokio::spawn with a bounded channel dispatching to a fixed worker pool, enabling backpressure, fire-and-forget operations, and priority scheduling.
• Cancellation: Use CancellationToken to actively cancel backend operations on client disconnect, with safety invariants protecting tombstone writes from cancellation.

Ref FS-171

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.}

[jan-auer]

This default is chosen arbitrarily so that it is not unreasonably high, but still high enough to not limit in practice. We will tweak this.

[linear]

FS-171 Implement backpressure