feat(sdk/go): expose tags search filter on Find and Search

[r266-tech]

What

Adds a Tags []string option to the Go SDK FindOptions / SearchOptions and forwards it as payload["tags"] to /api/v1/search/find and /api/v1/search/search, closing a read/filter parity gap: the server and Python SDK accept a validated tags retrieval filter that the Go SDK currently cannot send.

Why

The server already consumes tags end-to-end:

• openviking/server/routers/search.py — FindRequest.tags / SearchRequest.tags (Optional[List[str]] = None, under model_config = ConfigDict(extra="forbid")); the handlers pass request.tags into normalize_search_tags(...) → a search_tags must-filter.
• openviking/storage/collection_schemas.py — search_tags is a first-class list<string> collection field.
• Python SDK exposes it: openviking/client/local.py find(tags=...) / search(tags=...).

The Go SDK had no way to send it — sdk/go/types.go FindOptions / SearchOptions carried Since / Until / TimeField / Level but no Tags, and sdk/go/retrieval.go never set tags in the payload. So tag-scoped retrieval was unreachable from Go.

This is strictly a read/filter parity fix. (Note: the Go SDK does not expose set_tags either; tags are populated server-side / via the Python set_tags path / #2706. This PR only lets Go callers filter by tags the server has validated.)

Change

• types.go: append Tags []string to both option structs.
• retrieval.go: in Find and Search, add if len(opts.Tags) > 0 { payload["tags"] = opts.Tags } right after the level block — omitting the key when empty, exactly mirroring the existing filters.
• client_test.go: extend the existing filter tests to assert tags is forwarded when set and absent when unset.

Follow-up to #2703, which added since/until/time_field/level to the same Find/Search funcs in the same three files the same way.

Compatibility

Tags is appended at the end of the option structs, so it does not reorder or change the type of any existing field. The SDK's option structs are used with keyed literals (e.g. FindOptions{TargetURI: ..., Limit: ...}), which are unaffected; the only theoretical impact is an unkeyed positional literal of these option structs (which go vet's composite-literal check already flags for cross-package structs). This matches the additive convention accepted in #2703.

Verification

go build ./..., go vet ./..., gofmt -l . (clean), and go test ./... all pass in sdk/go.

[github-actions]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

🎫 Ticket compliance analysis ✅ 2703 - Fully compliant Compliant requirements: Expose Tags []string on FindOptions/SearchOptions Forward tags to /api/v1/search/find and /api/v1/search/search Add tests for tags population and omission

⏱️ Estimated effort to review: 2 🔵🔵⚪⚪⚪

🏅 Score: 95

🧪 PR contains tests

🔒 No security concerns identified

✅ No TODO sections

🔀 No multiple PR themes

⚡ No major issues detected

[github-actions]

PR Code Suggestions ✨

No code suggestions found for the PR.