Fix array-type filter conditions (ObjectsFilterItem, MultiSelectFilterItem)

[themightychris]

Summary

Fixes the failed to build expression filters error when using in, all, or nin conditions on array-type properties (objects, multi_select, files) in the Search API.

Problem

The filter item types (ObjectsFilterItem, MultiSelectFilterItem, FilesFilterItem) return []string from their GetValue() methods, but SanitizeAndValidatePropertyValue expected []interface{}. This type assertion failure caused all array-based filter conditions to fail.

Additionally, the links property (a derived system property) was incorrectly validated to require object/member layouts, but it can contain references to any object type (files, types, pages, etc.).

Changes

• core/api/service/property.go:

  • SanitizeAndValidatePropertyValue now accepts both []string and []interface{} for objects, files, and multi_select property formats
  • Added isValidObjectReferenceForProperty() that relaxes validation for the links property

• core/api/filter/expression_test.go: Added tests for ObjectsFilterItem with in/all conditions

• core/api/service/property_test.go: Added tests for SanitizeAndValidatePropertyValue handling []string input for objects and multi_select formats

Test Plan

• All existing tests pass
• New tests verify []string input is accepted for objects properties
• New tests verify []string input is accepted for multi_select properties
• New tests verify links property accepts any object type (e.g., files)

Fixes #2897

🤖 Generated with Claude Code

[socket-security]

No dependency changes detected. Learn more about Socket for GitHub.

👍 No dependency changes detected in pull request

[themightychris]

Note: This PR has significant overlap with #2880 by @stevelr, which also fixes the []string type assertion bug for array-type filters.

Differences:

• Our approach handles []string directly without converting to []interface{}
• core/api: allow type object ids in type filters #2880 special-cases the type property to allow objectType layout
• This PR special-cases the links property to allow any object type (files, types, pages, etc.)

Both PRs address the core issue reported in #2897. It may make sense to combine the special cases from both approaches.