chore(config): delete the dead rate_limit.* settings and prune their existing rows

[ericfitz]

Summary

Follow-up to #809, per the decision recorded there on 2026-08-23.

rate_limit.requests_per_minute and rate_limit.requests_per_hour are dead:
nothing in the codebase reads either value. Actual rate limiting is driven by
server.disable_rate_limiting and server.ratelimit_public_rpm, which are
separate, classified, and live.

#812 classified both keys, which was the behavior-preserving fix — it cleared the
live 404-on-GET-for-a-listed-key inconsistency. But classification leaves two
settings an administrator can read and edit that silently do nothing, which is
arguably a worse trap than the 404 it replaced, since a 404 at least fails loudly.

This issue removes them.

Acceptance Criteria

• rate_limit.requests_per_minute and rate_limit.requests_per_hour are removed
  from the SettingDef registry in internal/config/setting_defs_*.go, and therefore
  from the DefaultSystemSettings() and GetMigratableSettings() projections.
• The transitional ratchet baseline and any pinned key-count assertions introduced by
  feat(config): make one registry the authoritative declaration of every setting #812 are updated to reflect the removal, and still may only shrink.
• A cleanup removes the existing rows from databases that already have them.
  Both k3s and RDS hold these rows today — leaving them as orphans would
  reintroduce exactly the list-but-404 shape fix(api): rate_limit.* settings are listed but 404 on GET/DELETE — unclassified keys seeded straight into the database #809 was about, since a row with no
  registry entry resolves to VisibilityInternal.
• cmd/dbtool is updated in line with the schema/seed change, per the project's
  dbtool-follows-schema rule.
• The doc comments that use rate_limit.requests_per_minute as an illustrative
  example (api/models/system_setting.go:13, and the generated example in
  api/api.go) no longer reference a key that does not exist. The api/api.go
  occurrence comes from the OpenAPI spec, so the example changes in
  api-schema/tmi-openapi.json and is regenerated.
• A guardrail test demonstrates the removal: planting either key back must fail a
  test by name. (Per the rule established in feat(config): make one registry the authoritative declaration of every setting #812 — a guardrail nobody has watched
  fail is not evidence.)

Notes

• This is a behavior change, which is why it did not ride on feat(config): make one registry the authoritative declaration of every setting #812.
• Considered and rejected: wiring the keys to the rate limiter so they do what their
  names promise. That is a feature (per-user rate limits), needs its own design, and
  is not what the names currently imply is already happening.
• Oracle review required — this touches the seed path and adds a data cleanup, so
  oracle-db-admin must sign off before completion. Note the latent ORA-01400 that
  feat(config): make one registry the authoritative declaration of every setting #812's Oracle review found in SeedDefaults when reasoning about the seed loops.