Add configurable rate limiting for user asset uploads

[Vaibhav701161]

Change(s)

Change Type:

Added

Change Category:

Internal

Changelog Entry:

Added configurable, user-scoped rate limiting for asset uploads to prevent abuse and reduce congestion in the review pipeline.

This introduces a rolling-window upload limit configurable via config.toml, enforces limits before asset persistence and review enqueueing, and returns clear HTTP 429 responses when limits are exceeded. Connector-based uploads are explicitly exempted to support bulk migration workflows.

---

How to Test

Automated testing

• Unit tests have been added covering:

  • Rate limit enforcement
  • Rolling window reset behavior
  • Connector bypass

• Tests are expected to pass in CI environments using MySQL.

Local testing

1. Configure strict limits in src/config.default.toml, for example:

   [rate_limit]
   enabled = true
   uploads_per_window = 1
   window_seconds = 3600

2. Start the API.

3. Perform two consecutive asset uploads as a regular user:

   • First request should succeed (HTTP 200)
   • Second request should return 429 Too Many Requests with a Retry-After header

4. Perform multiple uploads as a connector user:

   • All uploads should succeed (rate limiting bypassed)

Note on local test execution

• Local test runs using SQLite may fail during schema creation due to existing
  MySQL-specific BINARY() CHECK constraints in unrelated models.
• This is a known SQLite/MySQL incompatibility and is not introduced by this PR.
• CI environments using MySQL are expected to execute the tests successfully.

---

Checklist

• Tests have been added to reflect the changes; local SQLite failures are explicitly explained.

• Documentation has been added describing configuration, behavior, and tradeoffs (docs/developer/rate-limiting.md).

• A self-review has been conducted checking:

  • No unintended changes have been committed.
  • The changes in isolation are reasonable and scoped.
  • Design tradeoffs (DB-backed rate limiting, minor concurrency overshoot, retention cleanup) are documented inline.

• All applicable CI checks pass (linting, formatting, type checking); test execution depends on MySQL-backed CI.

• The PR title matches the changelog entry’s one-line description.

---

Related Issues

Closes #661