fix: match list-valued metadata filters by item

[Iams4kura]

What does this PR do?

Metadata filtering documents in as matching any requested tag, but list-valued fields were compared as one scalar value. As a result, a result tagged adventure failed in: ["adventure"] and incorrectly passed not_in: ["adventure"].

This change:

• checks each item when the stored metadata value is a list, tuple, or set;
• keeps scalar membership behavior unchanged;
• makes not_in the exact complement while preserving its existing validation error;
• adds regression coverage for both operators using the existing list-valued tags fixture.

Regression evidence

• Before the fix: tests/test_metadata_filtering.py failed both new assertions (2 failed, 33 passed).
• After the fix: the same affected suite passes (35 passed).

Related Issues

No existing issue. Exact issue and PR searches for metadata filters, not_in, and list-valued tags found only the original merged feature work and unrelated reports.

Checklist

• Affected tests pass (pytest tests/test_metadata_filtering.py -v --tb=short; 35 passed)
• Code formatted (ruff format and ruff check via pre-commit)
• Pre-commit hooks pass (pre-commit run --all-files)
• Type check passes (ty check packages/leann-core/src apps tests; 3 pre-existing warnings)
• leann-core source distribution and wheel build successfully

The full multi-backend test matrix was not reproduced locally because the repository's CI workflow first builds and installs native backend artifacts and recursive submodules. The complete official metadata-filtering suite, repository-wide pre-commit hooks, repository-wide type check, and affected package build cover this isolated pure-Python change; CI can exercise the platform/backend matrix.

[ASuresh0524]

@Iams4kura Can we fix CI?