Issue Summary:

Forge apps with fullPage modules cannot function across both Jira and Confluence in a cross-context app (XCA) configuration. When an app defines both jira:fullPage and confluence:fullPage modules, the manifest validation fails because fullPage modules must match the required product. Since only one product can be set as required: true, it is impossible to have fullPage modules for both products in a single app. This contrasts with globalPage modules, which work correctly in dual Jira/Confluence installations.

Steps to Reproduce

1. Create a Forge app with both jira:fullPage or confluence:fullPage modules in the manifest.
2. Configure app.compatibility with jira: required: true and confluence: required: false.
3. Run forge lint or attempt to deploy the app.

Expected Results

The app should allow fullPage modules for both Jira and Confluence in a cross-context configuration, similar to how globalPage modules work across both products.

Actual Results

The following validation errors are thrown:

35:2    error    Using the module `confluence:fullPage` is invalid when the required product is Jira. Full page modules must match the required product. Use `jira:fullPage` as the module type, or change the required product to Confluence in your manifest.yml compatibility settings.  valid-document-required

Additionally, if both products are set to required: true, the validation still fails. If only one product is required and the app is installed on both, fullPage modules for the non-required product result in a "claim mismatch" error at runtime.

27:2    error    Using the module `jira:fullPage` is invalid when the required product is Confluence. Full page modules must match the required product. Use `confluence:fullPage` as the module type, or change the required product to Jira in your manifest.yml compatibility settings.  valid-document-required

437:2   error    One context (Jira, Confluence, or Compass) must have `required:true` in app.compatibility.  valid-document-required

Workaround

Currently, there is no known workaround for this behavior. A workaround will be added here when available