Content Drive: decide whether folder listings should be scoped to their own site

Description

Follow-up from issue #37148 item 1 (spec'd in #37230, materialized folder-first CTE fix). Split out per review feedback on #37230: the CTE/tiebreaker performance fix and this host-scoping correctness question are independent, and bundling them was blocking the performance fix on a product decision.

The question: should a Content Drive folder listing be scoped to the folder's own site, or is it correct for it to return content from other sites that happen to share the same relative path?

Background: BrowserAPIImpl.selectQuery computes shouldApplySiteFiltering = !browserQuery.ignoreSiteForFolders && browserQuery.folder != null (dotCMS/src/main/java/com/dotcms/browser/BrowserAPIImpl.java:1958-1959). When ignoreSiteForFolders is true, no host/site filter is appended to the candidate-scan query at all.

ContentDriveHelper (dotCMS/src/main/java/com/dotcms/rest/api/v1/drive/ContentDriveHelper.java:161-166) sets ignoreSiteForFolders(true) deliberately, for every Content Drive request that targets a specific folder (not the site root):

builder.withHostOrFolderId(folder.getInode())
    // When a specific folder is selected, enable ignoreSiteForFolders to allow
    // folder selection without being limited by site filtering
    .ignoreSiteForFolders(true);

Per git blame, this was authored by Jose Castro (most recently touched in commit f4ff8039).

The effect: if two different sites have a folder with the same relative path, Content Drive's listing for "one" of those folders today returns content from both sites. Issue #37148 flagged this as a correctness defect. But the ContentDriveHelper comment reads like an intentional design choice (letting a folder selection work independent of which site is active), so it isn't clear whether the cross-site result is a bug or a feature.

What's needed: a decision from Jose (or whoever owns this behavior) on whether:

• (a) Content Drive folder listings should be scoped to their own site — in which case the fix is to stop setting ignoreSiteForFolders(true) for this case, or to add the site/host_inode filter back in some other way, and the cross-site result stops being returned; or
• (b) the cross-site behavior is intentional and should stay as-is — in which case #37148's correctness finding for this case should be closed as "won't fix" / working as intended, with the reasoning documented for future readers.

Acceptance Criteria

• Decision recorded: is Content Drive's folder listing intended to be site-scoped or not?
• If site-scoped: a spec is written for the fix (likely re-adding host_inode to the candidate-scan query for this case) and the ContentDriveHelper comment is corrected to no longer describe the cross-site behavior as intentional.
• If not site-scoped: issue #37148's correctness finding for this case is closed as working-as-intended, with the reasoning added to ContentDriveHelper's comment so a future reader doesn't reopen it as a bug.

Additional Context

Related: #37148, #37230 (the performance fix this was split out of — #37230 does not depend on this decision and can proceed independently).

Read BrowserAPIImpl.java around selectQuery and ContentDriveHelper.java around the ignoreSiteForFolders setting, then review issues #37148 and #37230. Ask the behavior owner to decide whether folder listings are site-scoped; done means the decision is recorded and the appropriate fix specification or working-as-intended rationale is documented.