SDK: Add Query Builder Method to Include System Host Content

[rjvelazco]

Description

The dotCMS SDK Content Query Builder should provide a fluent and type-safe way to include System Host content when fetching collections.

Currently, developers must manually modify the Lucene query string to include +conhost:SYSTEM_HOST. This approach reduces discoverability, increases the risk of malformed queries, and breaks the fluent API pattern established by the SDK.

This task introduces a new chainable method to the client.content Query Builder that programmatically injects the required Lucene constraint to include System Host content.

The method will not introduce a new REST parameter. Instead, it will modify the internally generated Lucene query by appending:

+conhost:SYSTEM_HOST

The method should be idempotent and should not duplicate the constraint if called multiple times.

Proposed API

client.content
  .getCollection<Blog>('Blog')
  .includeSystemHost()
  .limit(10)
  .query((q) => q.field('author').equals('John Doe'))
  .then(...)

Acceptance Criteria

• Add a new chainable method to the Query Builder: .includeSystemHost(enabled?: boolean)
• Calling .includeSystemHost() or .includeSystemHost(true) injects +conhost:SYSTEM_HOST into the generated Lucene query
• Calling .includeSystemHost(false) ensures the constraint is not added
• The constraint is not duplicated if the method is called multiple times
• The implementation modifies the internal query builder state (not raw string concatenation at the final stage)
• TypeScript interfaces are updated to expose the new method with proper typing
• Unit tests validate:
  • Correct query generation
  • Boolean toggle behavior
  • Idempotency
• Verified against a staging environment to confirm expected results

Priority

Medium

Additional Context

• The SDK relies on Lucene syntax for query construction, so this enhancement modifies the generated query instead of introducing a new API parameter.
• The method does not replace existing host filtering logic and does not change the current host context.
• The goal is to improve developer experience and maintain consistency with the SDK’s fluent API design.
• Future enhancements may consider a more generic host inclusion API if broader host-scoping capabilities are required.