Defkit: Lit 支持结构化 Go 值,但会渲染出无效的 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.