[CLN] Normalize nil-handling across V2 SearchRequestOption helpers

[tazarov]

Summary

Phase 22 intentionally made WithGroupBy(nil) fail fast instead of silently acting as omission. That leaves sibling SearchRequestOption paths with inconsistent nil semantics in pkg/api/v2/search.go.

Today, callers can still pass explicit nil-like values in some other search option helpers and get silent omission or inconsistent behavior. This follow-up should make the V2 Search API present a uniform contract for explicit nil / absent option input.

Problem

Current option behavior is inconsistent:

• WithGroupBy(nil) now returns a validation error
• searchFilterOption.ApplyToSearchRequest still accepts a nil filter as a silent no-op
• rankOption.ApplyToSearchRequest still accepts a nil rank as a silent no-op
• WithSelect(nil...) / related empty-or-nil option inputs do not follow the same explicit contract

That makes the API harder to reason about and risks more silent intent loss when callers thread optional values into functional option lists.

Goal

Define and implement a consistent nil-handling contract for V2 SearchRequestOptions.

Scope

• Audit sibling SearchRequestOption implementations in pkg/api/v2/search.go
• Decide which explicit nil inputs should be rejected vs treated as omission
• Add targeted tests that pin the selected contract for each affected option
• Preserve backward compatibility where a stricter change is not justified, or document/flag any intentional breaking behavior

Initial candidates

• searchFilterOption.ApplyToSearchRequest
• rankOption.ApplyToSearchRequest
• select-related option helpers in pkg/api/v2/search.go

Context

Follow-up from PR #502 review on Phase 22 (WithGroupBy(nil) validation).