cluster_policies: Stop allowing Sequence types for value

[Sankalp-Mittal]

Changes

Reject inline sequence (list) values for the cluster policy definition and policy_family_definition_overrides fields. Previously a top-level YAML sequence was marshaled to a JSON array string and sent to the backend as-is; it is now rejected during bundle validation with <field> must be a string or map, got sequence.

Why

A cluster policy definition must be a JSON object (a map of attribute paths to constraint objects). A top-level sequence is valid JSON but never a valid policy, and the backend does not validate the definition shape at create time — so without this change the broken policy is accepted and the failure is deferred.

Concretely, for:

resources:
  cluster_policies:
    my_policy:
      definition:
        - foo: bar
  jobs:
    my_job:
      ...
      policy_id: ${resources.cluster_policies.my_policy.id}

• Before this PR: bundle deploy succeeds — the backend accepts the array definition, returns a policy_id, and stores it verbatim (it is never marked invalid), and the job is created. The failure only appears when the job runs: launching the job cluster applies the policy, and the backend rejects it with INVALID_PARAMETER_VALUE: Requests for the policy ... cannot be satisfied due to the malformed policy definition. Please contact your administrator to correct the policy definition. — an error far from the bundle config that gives no hint the cause is the list under definition.
• After this PR: bundle validate / bundle deploy fails immediately with definition must be a string or map, got sequence, pointing straight at the offending config.

(Verified against the Azure backend and confirmed in the backend source: create-time validation only does field-presence .has(...) checks, which pass for an array; the array only fails later during enforcement in ClusterPolicyDefinition.fromJson.)

Tests

Unit tests.

This pull request and its description were written by Isaac.

[janniklasrose]

The backend doesn't do validation at create time and defers it till it is applied and then throws an error.

Can you be more specific how this impacts DABs users?

resources:
  cluster_policies:
    my_policy:
      definition:
        - foo: bar

  jobs:
    my_job:
      ...
        my_cluster:
          policy_id: ${resources.cluster_policies.my_policy.id}

will this fail when the job is deployed? when the job is run?