tfExpression/HCL renderer: object keys are rendered into expressions without escaping

[so0k]

Latent bug (pre-existing at the merge base of #296)

TFExpression.resolveExpressionPart (packages/cdktn/src/tfExpression.ts) renders object arguments key by key as:

`"${key}" = ${this.resolveArg(context, arg[key])}`

The key is interpolated into the quoted Terraform string literal verbatim. A key containing a quote, backslash, control character, ${...}, or %{...} therefore either produces an invalid Terraform expression or silently turns the literal key into a Terraform template sequence.

Repro scenarios

// 1. Quote in key: renders {"he"llo" = "x"} - invalid HCL
new TerraformOutput(stack, "out", {
  value: Fn.lookup(Token.asAny({ 'he"llo': "x" }), "other"),
});

// 2. Template marker in key: renders {"${injected}" = "x"} - the key
//    becomes a template interpolation instead of the literal string
Fn.lookup(Token.asAny({ "${injected}": "x" }), "other");

// 3. Backslash in key: renders {"a\b" = ...} - "\b" is an invalid (or
//    unintended control) escape in the resulting Terraform string literal
Fn.lookup(Token.asAny({ "a\\b": "x" }), "other");

Scope

• The direct-object branch of resolveExpressionPart (pre-existing).
• PR feat: support newer provider plugin-protocol features via targetVersions (RFC-04) #296 fixed the newly added resolvable-resolved-object branch (whole-collection tokens like Token.asAny({...}) passed to provider functions) to serialize keys as proper quoted-string literals (JSON.stringify + $${/%%{ template-marker escaping) — the same treatment should be applied here.
• Audit the HCL renderer's map/object rendering for the same pattern while at it.

See the discussion in #296 (review comment on tfExpression.ts and #296 (comment)).

[sakul-learning]

Additional edge case found while reviewing #296: the new quotedStringKey() helper uses JSON.stringify(). That correctly handles the practical quote, backslash, ${...}, and %{...} cases, but JSON emits U+0008 and U+000C as \b and \f; Terraform quoted strings reject both escape selectors. A complete shared key serializer should encode those characters using Terraform-compatible four-digit Unicode escapes instead.

This is non-blocking for #296: keys containing literal backspace or form-feed characters are exceptionally uncommon, the failure is explicit at Terraform parse time, and #296 already fixes the practical hostile-key cases in its newly added resolved-object path. Track the remaining serializer completeness here rather than expanding that PR further.

[jsteinich]

Folding in the second rendering path from #341, which I'm closing as a duplicate of this issue.

tfExpression.ts is only half of it — the same unescaped-key rendering exists in the HCL renderer:

• packages/cdktn/src/hcl/render.ts:178 and :542 — wrapIdentifierInQuotesIfNeeded() wraps a key in double quotes when it isn't a bare identifier, but never escapes the contents. A key containing ", \, ${...} or %{...} produces the same invalid-or-reinterpreted output described above.

Current state in tfExpression.ts, for anyone picking this up: quotedStringKey() (added in #296) is wired into the resolvable-object branch at line 76 only. The pre-existing direct-object branch below it still interpolates `"${key}" = ...` verbatim — the comment above quotedStringKey at line 20 already points here.

So the complete fix is three call sites, plus the \b / \f escape-selector gap noted above, ideally through one shared key serializer.