Ensure Navigation API Support `siteId` Parameter

Problem Statement

The Navigation API currently does not support specifying the site using a sideId, leading to inefficiencies in navigation retrieval for multi-tenant CMS setups with multiple sites. Developers have implemented workarounds, but adding direct support for site IDs would improve performance, reduce complexity, and enhance usability.

https://www2.dotcms.com/docs/latest/navigation-rest-api

Objectives

• Implement support for passing a siteId in the Navigation API to allow site-specific navigation retrieval.
• Ensure backward compatibility with existing API implementations.
• Update the API documentation to include the new siteId functionality.
• Provide robust error handling for invalid or missing siteIds.

User Story

As a website developer managing multiple sites within a multi-tenant CMS, I want the Navigation API to support site-specific navigation queries using a siteId, so that I can retrieve navigation data accurately and efficiently for each site.

```[tasklist]

Acceptance Criteria

• The Navigation API accepts and correctly processes a siteId parameter.
• The API response accurately reflects the navigation structure for the specified siteId.
• The implementation is backward-compatible and does not break existing API calls.
• Comprehensive testing is conducted across different siteIds to ensure consistent behavior.
• The API documentation is updated to reflect the new siteId parameter, with usage examples.
• Proper error messages are returned when invalid or missing site IDs are provided.
  \`

External Links

[Placeholder for external links to Slack conversations, support tickets, Figma designs, etc.]

Assumptions & Initiation Needs

• Assumes access to a test environment for validating the feature.
• Assumes developers have access to the site ID list and relevant configurations.
• Assumes the Navigation API infrastructure can be extended to support additional parameters without significant architectural changes.

Quality Assurance Notes & Workarounds

[Placeholder for QA notes, test cases, and temporary workarounds if applicable.]

Technical Details

• Ensure compatibility with existing API versioning.
• Potential need for schema updates or parameter validation logic to handle site IDs correctly.
• Performance benchmarks to ensure minimal overhead when site IDs are added as parameters.

Potential Challenges

• Ensuring minimal impact on existing clients using the Navigation API.
• Identifying edge cases, such as when a siteId does not match any available site.

Impact on Existing Features

• The addition of the siteId parameter should not disrupt current API functionality or cause regressions in existing workflows.

Start with the Navigation API implementation and its existing API versioning, parameter validation, and schema handling; the issue does not name specific files or tests. Trace current navigation retrieval and existing callers, then define completion through siteId-aware responses, backward-compatible calls, invalid or missing ID errors, coverage across sites, and updated Navigation REST API documentation.