Description of problem:

When trying to use the `copySecretData` template function inside of a standalone hub template on a ConfigurationPolicy (ie, when directly deploying the ConfigurationPolicy to the managed cluster, and not through the policy framework, where hub templates would be resolved on the hub...), depending on the exact template, it can fail with this error:

Secret in version "v1" cannot be handled as a Secret: json: cannot unmarshal string into Go struct field Secret.data of type map[string][]uint8 

But in other (very similar) templates, it will work as expected.

Version-Release number of selected component (if applicable):

2.13

How reproducible:

If you're careful, 100%. But it's a rather specific setup.

Steps to Reproduce:

1. Create a Secret on the hub cluster to pull data from.
2. Configure the standalone hub templating permissions so that a ConfigurationPolicy on the managed cluster can access the Secret on the hub.
3. Create a ConfigurationPolicy on the managed cluster, using the `copySecretData` template function inside of a hub template. Important: the template must span two lines, see below.
4. Observe the error.

Below is a snippet of a ConfigurationPolicy. The first definition, for `test-secret`, will have the problem. The second definition, for `test` will not.

  - complianceType: musthave
    objectDefinition:
      apiVersion: v1
      data: '{{hub copySecretData "open-cluster-management-policies" "test-secret"
        hub}}'
      kind: Secret
      metadata:
        name: test-secret
        namespace: test
    recreateOption: None
  - complianceType: musthave
    objectDefinition:
      apiVersion: v1
      data: '{{hub copySecretData "open-cluster-management-policies" "test" hub}}'
      kind: Secret
      metadata:
        name: test
        namespace: test
    recreateOption: None 

Actual results:

The policy is non-compliant with this templating error:

Secret in version "v1" cannot be handled as a Secret: json: cannot unmarshal string into Go struct field Secret.data of type map[string][]uint8  

If you look at the Secret created after the hub templates are resolved (this is a separate Secret from `test` or `test-secret`, it's more of an implementation detail inside of config-policy), you can see that the `data` field in problem the objectDefinition is just a string. On the working objectDefinition, it is the correct object.

Expected results:

Both objectDefinitions should work.

Additional info:

Originally reported on slack:  https://redhat-internal.slack.com/archives/CU4QXLPQB/p1749392557645289