Guard collection type-mapping parity across generator surfaces (table-driven test + shared-descriptor evaluation) #353

Collection type-mapping policy currently lives in four places with overlapping (but not identical) responsibilities:

• packages/@cdktn/provider-generator/.../attribute-type-model.ts — resource/provider argument input types, recursive list/set/map handling, computed stored-class selection
• packages/@cdktn/provider-generator/.../provider-function-model.ts — provider-function parameter types, jsii-safe return types, Token return wrappers (added in feat: support newer provider plugin-protocol features via targetVersions (RFC-04) #296; documents that it mirrors the attribute model "branch for branch")
• packages/@cdktn/hcl2cdk/src/coerceType.ts — Terraform collection -> Token.asXxx coercion
• packages/cdktn/src/functions/helpers.ts — the older, partial built-in-function return wrappers

Follow-up (from #296 (comment)):

1. Add a table-driven parity test for the overlapping resource-input/provider-function cases: primitive list/set/map types, boolean token handling, whole-collection IResolvable acceptance, nested degradation to any[]/IResolvable.
2. Evaluate whether a small shared semantic descriptor across the generator paths earns its maintenance cost, or whether the explicit mirroring comments remain the right guardrail.