fix: cap concurrent batch searches and rate-limit the API

[TITeee]

Problem

• POST /vulnerabilities/search/batch keeps Node's single JS thread busy for seconds. Measured on real data (the 1,000 packages with the most stored rows): about 12.7 s warm for 1,000 packages, 63 s the first time, 113 MB of response. While two batches ran, a single search that normally takes 2 ms took 1.4 s.
• Nothing limited how many batches ran at once, or how many requests a client could send. A leaked key or a runaway client could keep the API busy for every other caller.
• A caller that gave up (heretix-management stops waiting after 60 s) left the work running to the end.

Changes

• At most BATCH_SEARCH_MAX_CONCURRENT (default 2) batch searches run at once. Another gets 429 with Retry-After: 5 before any work starts, so it holds no connection or parsed body while waiting.
• A batch whose caller has disconnected is dropped at the next chunk of 20 packages and its slot is freed. In a manual run (1,000 packages, client aborts at 1 s) the slot was free again 0.2 s later.
• @fastify/rate-limit per client address: RATE_LIMIT_MAX per minute (default 1200) for everything but /health, and RATE_LIMIT_BATCH_MAX (default 30) for the batch search. 0 turns a limit off.
• Docs: docs/operations.md (environment variables, why) and docs/api.md (429).

The rate limit is a backstop: heretix-management reaches the API from one address with one shared key, so a per-address limit cannot tell it from a misuser. The concurrency cap is the main protection.

Not in this PR

• Streaming the batch response (NDJSON) to cut the peak memory. It needs heretix-management to read it, so it is a separate change.
• heretix-management does not retry on 429 yet; it sends batches one after another, so it is only hit when several scans run at once.

Test plan

• vitest (747 tests), tsc --noEmit, eslint src
• Integration tests (5 new, 53 in total): global and batch rate limit, RATE_LIMIT_MAX=0, /health never limited, concurrent batch gets 429 and the next one is let in, an invalid batch frees its slot
• Manual: client disconnect drops the batch and frees the slot
• After deploy, run a scan from heretix-management and confirm no 429