Display Branch Scoped Resources in disabled Branches as Read Only Objects

Summary
When using Git synchronization with separate branches for test and production environments, branch scoped resources that exist only in another branch are completely hidden from the UI. This prevents administrators from preparing or modifying those resources before promotion.
I would like to request an enhancement so that branch scoped resources remain visible in all branches while respecting their execution scope.

Current Setup
Our environment uses PowerShell Universal Git synchronization with two separate instances:

• Test server → connected to the test branch
• Production server → connected to the main branch

Changes are made only on the test system. Promotion to production is performed through a Git pull request from test to main.
The production instance is configured with OneWay synchronization, ensuring that changes can only be made in the test environment.
PowerShell Universal already allows assigning resources to specific branches so that they are only active in the intended branch.

Problem
Assume a Schedule is assigned exclusively to the main branch.
Because this resource does not belong to the test branch, it is completely absent from the Test UI.
As a result:

• The Schedule cannot be reviewed in the Test environment.
• Future changes cannot be prepared before promotion.
• Administrators must switch to the Production system to understand the current configuration.
• The Git based promotion workflow becomes inconsistent because some resources can only be managed in one environment.

Proposed Enhancement
Introduce a read only branch visibility mode for branch scoped resources.

Behavior:

• Resources assigned to another branch should still be displayed in the UI.
• Such resources should be visually marked, for example:
  • Greyed out
  • Lock icon
  • "Available in branch: main" indicator
• Resources should remain editable so that changes can be prepared and committed in the current branch.
• Runtime behavior must continue to respect branch assignment.

For a Schedule this would mean:

• The Schedule is visible in the test branch.
• The Schedule does not execute in the test environment.
• The associated script is not started in the test environment.
• Administrators can still modify the Schedule configuration and submit the change through the existing Git workflow.

Benefits

• Improved visibility across environments.
• Better support for Git based promotion workflows.
• Reduced need to switch between environments.
• Easier maintenance of production only resources.
• Consistent user experience across all resource types.