[Quality] Rate-limit verifier queue and decision endpoints

[1nonlypiece]

Problem

Verifier endpoints can be polled or submitted repeatedly, creating avoidable load and increasing the chance of decision races.

This issue requires a meaningful production implementation. Typo-only, documentation-only, formatting-only, dependency-only, or cosmetic changes do not satisfy the scope.

Objective

Add identity-aware rate limits and abuse-resistant controls without blocking legitimate review sessions.

Scope

Define limits by route and actor, return retry metadata, exempt safe health checks, and ensure failed authorization does not reveal sensitive queue data.

Acceptance criteria

• Limits are enforced consistently across instances using the configured store.
• Clients receive a documented 429 response and retry guidance.
• Decision submission remains idempotent under retries.
• Load tests demonstrate bounded backend work under abusive polling.
• Existing CI/CD checks remain green.
• The PR explains the design, tradeoffs, test evidence, and any remaining limitations.
• The PR references this issue with Closes #{issue-number} or Fixes #{issue-number}.

Implementation notes

Implement only the stated behavior; keep unrelated refactors out of the PR.

Non-goals

• Do not remove tests merely to make CI pass.
• Do not introduce secrets, private keys, credentials, or mainnet-only values.
• Do not change unrelated APIs, UI surfaces, contract behavior, or deployment configuration.

Contributor application

Before starting, comment with relevant experience, a 1–4 bullet implementation approach, and an estimate for opening the first draft PR. Wait for maintainer assignment before coding. Only the assigned contributor is eligible for reward consideration.

Submission requirements

• Use PR title format [#<issue-number>] <short summary>.
• Check off each completed acceptance criterion.
• Include focused automated tests for success, failure, authorization, and boundary behavior where applicable.
• Include the validation commands and results in the PR description.
• Address maintainer review feedback before merge.

GrantFox reward consideration is based on the original scope, implementation quality, tests, security review, CI/CD results, review feedback, and follow-up stability; completion or merge alone is not a guarantee.

[guptakumarranjeet150]

Hi everyone,

I would love to take this on. My planned approach:

• Structure backend handlers for [Quality] Rate-limit verifier queue and decision endpoints with strict input validation, proper HTTP error codes, and idempotent execution.
• Cover implementation with end-to-end integration tests for standard and edge-case inputs.

Looking forward to contributing—please feel free to assign!