fix: missing query params in openapi specs

[smitt14ua]

Summary

Specify query parameters in the GET /api/v1/operations method OpenAPI specification to prevent next warnings to be logged:

{"time":"...","level":"WARN","msg":"query parameter not expected in OpenAPI spec","param":"name","expected_one_of":["Accept"]}
{"time":"...","level":"WARN","msg":"query parameter not expected in OpenAPI spec","param":"older","expected_one_of":["Accept"]}
{"time":"...","level":"WARN","msg":"query parameter not expected in OpenAPI spec","param":"newer","expected_one_of":["Accept"]}
{"time":"...","level":"WARN","msg":"query parameter not expected in OpenAPI spec","param":"tag","expected_one_of":["Accept"]}

How to test

A. See logs
B. Check Swagger UI

Checklist

• go test ./... passes
• No breaking changes (or documented below)

[gemini-code-assist]

Code Review

This pull request updates the /api/v1/operations endpoint to include explicit OpenAPI documentation for query parameters such as name, date filters, and tags using option.Query. It also includes minor import reordering and formatting adjustments. A review comment suggests a more idiomatic refactoring by using fuego.ContextWithQuery in the handler signature, which would automate both the documentation and the parameter binding, thereby reducing boilerplate code.

[fank]

Root cause analysis: correct

Fuego derives declared query/header params for OpenAPI from the second generic type parameter of the handler context. Switching GetOperations from ContextNoBody (no params declared) to fuego.Context[any, Filter] makes Fuego pick up the query:"..." tags already present on Filter (operation.go:62-67), and the runtime warnings stop. Pure type-signature fix, no field churn — good.

Scope check: correct

I grepped internal/server for production-handler QueryParam calls — GetOperations is the only handler that uses query params. Every other typed handler is either PathParam-only (which Fuego derives from the route definition, not the context type) or has no params. So no other endpoints are silently emitting the same warning.

Tests: missing regression coverage

The mock-context updates are mechanical and fine. But there is no test asserting the spec actually declares name, older, newer, tag for GET /api/v1/operations. openapi_ui_test.go only validates the Swagger UI HTML references the spec URL — nothing inspects the spec body itself. The warnings this PR fixes come from Fuego's own runtime check; if the context type regresses, no Go test will catch it.

Ask: add a small regression test that decodes the server's openapi.json, walks to the /api/v1/operations GET operation, and asserts the four query parameters are declared. Keeps the fix locked in atomically.

Minor (non-blocking) observations

• The handler still does manual c.QueryParam("name") extraction. With fuego.Context[any, Filter] Fuego will bind a Filter for you — the manual reads are now redundant but harmless. Switching to bound params would mean more test churn; leaving as-is is fine.
• Stray noise in the diff (import reordering in handler.go and integration_test.go, struct-field re-alignment in Handler, trailing-newline removal at EOF of handler_test.go). Looks like gofmt running on previously-unformatted files. Same noise appeared in #424's diff — a gofmt -w ./... pass on main would quiet future PRs.