Subtask for the following items from the parent issue:

8) The messaging-activemq broadcast-group resource has problematic 'start' and 'stop' ops. These are not registered as runtime-only, but they are. They are registered on the profile resource and are not read-only, so the DC rolls them out to the domain. So, they are pre-existing ops that break the no-runtime-only-on-profile rule that WFCORE-389 is about rescinding. We have two
options here:
a) remove these ops on the profile as violations of the no-runtime-only-on-profile rule. This would be a breaking change. But it may be the correct thing to do anyway if it is unsafe to invoke these on the profile and have that roll out to all servers.
b) Correct the description of these to declare runtime-only.

Task for this is to make a decision.

9) The messaging-activemq broadcast-group resource also has problematic a get-connector-pairs-as-json op. This is a read-only op so it currently will not roll out. It will also fail if executed against the profile resource, as it fails if there is no activemq server present. So, the options here are:
a) Remove the op from the profile resource. It never worked anyway.
b) Allow them to roll out. This would be new behavior though.
c) Add OperationEntry.Flag.HOST_CONTROLLER_ONLY to the operation definition to prevent that rollout.
IMHO option c) is kind of silly, leaving a broken op in place, but it's a valid "emergency" step to prevent roll out inadvertently being turned on while a decision between a) and b) is made. So that's what will be done as part of this work.

As part of the parent task, option c) will be put in place. Task here is to decide final resolution.

10) The messaging-activemq cluster-connection resource has problematic 'start' and 'stop' ops. These are not registered as runtime-only, but they are. They are registered on the profile resource and are not read-only, so the DC rolls them out to the domain. So, they are pre-existing ops that break the no-runtime-only-on-profile rule that WFCORE-389 is about rescinding. We have two
options here:
a) remove these ops on the profile as violations of the no-runtime-only-on-profile rule. This would be a breaking change. But it may be the correct thing to do anyway if it is unsafe to invoke these on the profile and have that roll out to all servers.
b) Correct the description of these to declare runtime-only.

Nothing was done re: this in the parent task.

11) The messaging-activemq cluster-connection resource also has problematic a get-nodes op. This is a read-only op so it currently will not roll out. It will also fail if executed against the profile resource, as it fails if there is no activemq server present. So, the options here are:
a) Remove the op from the profile resource. It never worked anyway.
b) Allow them to roll out. This would be new behavior though.
c) Add OperationEntry.Flag.HOST_CONTROLLER_ONLY to the operation definition to prevent that rollout.
IMHO option c) is kind of silly, leaving a broken op in place, but it's a valid "emergency" step to prevent roll out inadvertently being turned on while a decision between a) and b) is made. So that's what will be done as part of this work.

As part of the parent task, option c) will be put in place. Task here is to decide final resolution.