docs/SECURITY.md's rate-limiting row doesn't name the tunable RATE_LIMIT_* env vars

## What

docs/SECURITY.md's rate limiting row names the routes that are rate limited, but never names the env vars that tune the limits themselves.

## Where

docs/SECURITY.md:35:

```
| 1.2 | Login, AI and database-reaching routes are rate limited | Implemented | [`src/lib/api/rate-limit.ts`](../src/lib/api/rate-limit.ts) | ... |
```

None of `RATE_LIMIT_AI_MAX`, `RATE_LIMIT_AI_WINDOW_SEC`, `RATE_LIMIT_QUERY_MAX`, `RATE_LIMIT_QUERY_WINDOW_SEC`, `RATE_LIMIT_ANON_MAX`, `RATE_LIMIT_ANON_WINDOW_SEC`, `RATE_LIMIT_LOGIN_MAX`, `RATE_LIMIT_LOGIN_WINDOW_SEC`, `RATE_LIMIT_LOGIN_ACCOUNT_MAX` or `RATE_LIMIT_LOGIN_ACCOUNT_WINDOW_SEC`, all documented in .env.example, are mentioned anywhere else under docs/.

## Expected

docs/SECURITY.md points a reader at where these limits are configured.

## How to fix

Add a short line near row 1.2, or in the paragraph below the table, pointing to .env.example's rate limiting section, or listing the var names directly.

## How to check

Someone reading docs/SECURITY.md's security posture table can find out how rate limits are tuned without already knowing to grep .env.example.

Start at docs/SECURITY.md:35 and compare the rate-limiting row with the rate-limiting section in .env.example; src/lib/api/rate-limit.ts is the referenced implementation. Add a short pointer or the relevant RATE_LIMIT_* names so readers can find how limits are tuned, then verify the security table makes that path clear.

Written by the indexing model from the issue text.