/**
 * `HttpErrors.BadRequestError` (HTTP 400) is reserved for genuine input
 * validation. Throwing it where the upstream caller's input was already
 * accepted — i.e. after the provider rejected the request — mislabels the
 * failure. Per repo policy: prefer `HttpErrors.UnprocessableEntityError`
 * (422); the frontend absorbs 400s and would mask the real cause.
 *
 * Fires only on high-confidence misuse:
 *   - Inside a `catch` whose `try.block` provably contains an `await` (async
 *     I/O — provider, service helper, db query, fetch). Catches wrapping pure
 *     sync operations (JSON.parse, schema.validate, parseInt) are NOT flagged
 *     — those are legitimate input-validation throw points.
 *   - Within 3 statements after an `await provider.*` / `await Provider.*` in
 *     any enclosing block (function-boundary stop).
 *
 * Allowlisted message substrings (`/^Missing/i`, `/^Invalid/i`, `/required/i`,
 * `/must be/i`) skip the rule — those phrases describe input validation,
 * `BadRequestError` is correct there.
 */
import type { Rule } from 'eslint';
declare const rule: Rule.RuleModule;
export default rule;