Defkit: Lit accepts structured Go values but renders invalid CUE

Describe the bug

defkit.Lit takes any, and its Go doc says it builds a literal from any Go value. The renderer only handles strings, numbers and bools. Everything else falls through to fmt.Sprintf("%v"), so a nested map or slice comes out as Go debug output rather than CUE. That text goes straight into the generated definition, and the parse error you eventually see points at the CUE rather than at Lit.

• Lit accepts any
• formatCUEValue falls back to fmt.Sprintf

To Reproduce

defkit.Lit([]map[string]any{
    {
        "applyServerSideEncryptionByDefault": []map[string]any{
            {"sseAlgorithm": "AES256"},
        },
        "bucketKeyEnabled": true,
    },
})

renders as:

[map[applyServerSideEncryptionByDefault:[map[sseAlgorithm:AES256]] bucketKeyEnabled:true]]

and cue vet reports:

expected ']', found 'IDENT' bucketKeyEnabled

Expected behavior

Either encode JSON-compatible values as real CUE, or reject them with a clear error. The part that costs time is the silence: the value is accepted, and the failure shows up somewhere else entirely.

If it is fixed rather than restricted, CUE's Go-value encoder would be safer than formatting values by hand. Worth adding a regression test that parses the generated CUE, since a substring check would not have caught this.

Screenshots

Not applicable.

KubeVela Version

v1.11.0.

Cluster information

Not applicable. This fails while generating the definition.

Additional context

The builder form works and is what we use now, though it is wordy for static data:

defkit.NewArray().Item(
    defkit.NewArrayElement().
        Set("applyServerSideEncryptionByDefault",
            defkit.NewArray().Item(
                defkit.NewArrayElement().Set("sseAlgorithm", defkit.Lit("AES256")))).
        Set("bucketKeyEnabled", defkit.Lit(true)),
)