fix(filter): reject unknown filter operators instead of silently dropping the filter

[SAY-5]

Summary

Closes #282.

When a JSON request body specifies a filter with an unrecognized operator
(e.g. \"equals\" instead of \"eq\"), the filter package was silently
dropping that filter and running the query unfiltered. Endpoints that
return the first matching row therefore looked successful even though the
user's filter never reached the database.

The reproduction in the issue is exactly this:

{ \"filters\": [ { \"field\": \"meta_data.name\", \"operator\": \"equals\", \"value\": \"...\" } ] }

The body parses successfully (operator is just a string), Validate
checks logical_operator and field but not the per-filter operator, and
buildStandardCondition falls through its default branch returning an
empty condition. Build skips empty conditions, so the resulting SQL has
no WHERE clause for that filter — the API returns the first row it finds
with no error.

Fix

• Add IsValidOperator in internal/filter/operators.go, the
  operator-side counterpart to the existing IsValidLogicalOperator.
• Reject unknown operators in Validate with a descriptive error that
  lists the supported operators (eq, ne, gt, gte, lt, lte,
  in, between, like, ilike, isnull, isnotnull).
• This propagates as a 400 Bad Request from any endpoint that calls
  Build / BuildWithOptions, matching the existing handling of invalid
  fields and invalid logical operators.

The fix is minimal and additive — no signatures changed, no behavior
changes for valid operators, no new error categories.

Test plan

• New unit tests cover unknown operator (\"equals\") and empty
  operator on both `Validate` and `Build`.
• New `TestIsValidOperator` covers the operator-validation predicate.
• Existing tests still pass (`go test ./internal/filter/... ./api/...`).
• Verified regression: stashing the `Validate` change makes the new
  tests fail with the silent-drop behavior the issue describes.
• `go vet ./internal/filter/...` and `gofmt -l internal/filter/` clean.

[CLAassistant]

All committers have signed the CLA.

[jerry-enebeli]

Thank you for the PR @SAY-5

[jerry-enebeli]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

hi @SAY-5