[FEATURE] Per-client ingestion rate limiting

## Summary

Limit the number of log entries a registered client can ingest per second to protect storage, prevent one noisy application from flooding the server, and guard against accidental logging loops.

## Motivation

Without rate limiting a single misbehaving or misconfigured application can fill disk or exhaust database connections. This is especially important now that the UDP listener enables very high-frequency ingestion.

## Proposed schema change

```sql
ALTER TABLE clients
ADD COLUMN rate_limit_per_second INT UNSIGNED NULL DEFAULT NULL,
ADD COLUMN rate_limit_burst INT UNSIGNED NULL DEFAULT NULL;
```

`NULL` means no limit (default). Configurable per-client via `PUT /api/clients/{app_key}`.

## Behaviour

- **HTTP**: return `HTTP 429 Too Many Requests` with `Retry-After` header when exceeded
- **UDP**: silently drop packets when rate is exceeded
- **Algorithm**: token bucket per `app_key`, refilled at `rate_limit_per_second` tokens/sec with burst capacity of `rate_limit_burst`
- Rate limiter state lives in-process memory (resets on server restart)

## Acceptance criteria

- [ ] Migration adds `rate_limit_per_second` and `rate_limit_burst` columns
- [ ] HTTP ingestion returns `429` with `Retry-After` when limit exceeded
- [ ] UDP packets silently dropped when limit exceeded
- [ ] Token bucket algorithm correctly handles burst
- [ ] Rate limit config loaded from clients table at startup
- [ ] Cache flushed when client is updated (same as auth cache)
- [ ] Unit tests for token bucket logic
- [ ] `GET /api/clients/{app_key}` response includes current rate limit config

Begin by tracing the clients API, HTTP ingestion path, UDP listener, clients-table migration, and existing auth-cache behavior. Use the acceptance criteria to define done: token-bucket tests pass, HTTP and UDP limits behave as specified, configuration loads and flushes correctly, and the client response exposes both rate-limit fields.

Written by the indexing model from the issue text.