Document and validate that RateLimit.period is milliseconds #1007

Follow-up from the spike in #1004 (findings).

RateLimit.period is milliseconds everywhere in practice — resources/default-settings.yaml ships 1000, 60000, 900000, 3600000 — but nothing states it. The type is period: number (src/@types/settings.ts:25-29) and the validator only requires period > 0 (src/utils/settings-config.ts:585-601).

So an operator writing period: 60 in seconds gets a 60 ms window: a 1000× tighter limit, silently, and nothing in review catches it. That is the same class of mistake the spec change in nostr-protocol/nips#2498 was about, mirrored on the operator side.

Three small changes:

• Document the unit on RateLimit.period and on EventRateLimit/MessageRateLimit, which extend it.
• Add a comment to each limits.*.rateLimits block in resources/default-settings.yaml saying ms.
• Reject a non-integer or sub-millisecond period in validateRateLimitPeriods, and warn below some floor (1 s?) since a sub-second event window is almost certainly a unit mistake.