Fix statically_parse_unrendered_config stringifying list/dict config …

[Aastha204]

Resolves #16133

Problem

construct_static_kwarg_value in core/dbt/clients/jinja_static.py is typed -> str and unconditionally stringifies all config values parsed from Jinja {{ config(...) }} calls. This means literal lists and dicts like {{ config(cluster_by=['id']) }} produce unrendered_config['cluster_by'] == "['id']" (a string) instead of the native ['id'] (a list).

When upgrade_manifest_json_dbt_version re-derives unrendered_config from raw_code for a manifest with a different dbt_version, the stringified values overwrite native types via .update(). Since same_config / same_contents compare unrendered_config values with plain ==, this type mismatch causes state:modified to falsely flag models as changed — even when the SQL is identical.

This affects any model with a list/dict-valued config key declared inline (cluster_by, partition_by, grants, labels, meta, unique_key as a list, etc.) whenever state:modified compares manifests across different dbt versions.

Solution

Added a _try_evaluate_to_python helper that recursively converts Jinja AST nodes to native Python values where possible:

• Const → native value (str, int, float, bool, None)
• List → Python list (items evaluated recursively)
• Dict → Python dict (keys and values evaluated recursively)
• Tuple → Python tuple
• Neg → negated numeric value
• Everything else (Call, Name, Getattr, etc.) → string via _reconstruct_node (same as before)

Updated construct_static_kwarg_value to use this helper and changed its return type from -> str to -> Any. This ensures both the fresh-parse path and the upgrade path produce the same native types for literal config values, eliminating the type mismatch.

No changes were needed to _reconstruct_node, upgrade_unrendered_config, or the comparison logic in same_config / same_contents.

Checklist

• I have read the contributing guide and understand what's expected of me.
• I have run this code in development, and it appears to resolve the stated issue.
• This PR includes tests, or tests are not required or relevant for this PR.
• This PR has no interface changes (e.g., macros, CLI, logs, JSON artifacts, config files, adapter interface, etc.) or this PR has already received feedback and approval from Product or DX.