fix: propagate search_settings filters through agent tools and system context builder

[octo-patch]

Fixes #2244
Fixes #2245

Problem

Two related bugs caused search_settings filters (e.g. collection_ids) to be silently discarded, allowing agents to access documents outside the intended collection boundary:

Issue #2245 — _build_aware_system_instruction ignores collection filters

When use_system_context=True, the dynamic RAG system prompt is built by _build_documents_context, which calls get_documents_overview with only filter_user_ids. The filter_collection_ids extracted from search_settings was never forwarded, so the system prompt enumerated all documents regardless of any collection restriction.

Issue #2244 — GetFileContentTool ignores search_settings.filters

GetFileContentTool.execute created its own filter dict {"id": {"$eq": doc_uuid}} and ignored the search_settings.filters (e.g. collection_ids) available on the agent context. A document_id suggested by the LLM could therefore resolve to content from a different collection.

Solution

• _build_documents_context now accepts a filter_collection_ids parameter and passes it to get_documents_overview.
• _build_aware_system_instruction forwards filter_collection_ids when calling _build_documents_context.
• GetFileContentTool.execute merges context.search_settings.filters into an $and compound filter alongside the document-id predicate, so collection-scoped queries are enforced end-to-end.

Testing

The changes are purely additive — existing callers that do not supply filter_collection_ids retain the previous behavior (parameter defaults to None). The GetFileContentTool fix is backward-compatible: if no search_settings filters exist on the context, the tool behaves exactly as before.

Manual testing: reproduce the scenarios described in #2244 and #2245 with a collection_ids filter and verify that only documents belonging to the specified collection are returned.