fix(codegen): use literal string keys in SchemaTraitWriter to fix esbuild tree-shaking

[TrevorBurnham]

Fixes aws/aws-sdk-js-v3#7607

Problem

Since aws-sdk-js-v3 v3.930.0, ESBuild users have seen significant bundle size regressions when importing only a few commands from a client. For example, importing EC2Client and 3 commands grew from ~30KB to ~492KB.

SchemaTraitWriter.writeTraitsObject() emits computed property keys using StringStore variable references as object keys:

// generated output (before)
const _e = "error";
const _c = "client";
{ [_e]: _c, [_hE]: 400 }

ESBuild treats computed property keys ([expr]) as potentially having side effects because the expression could invoke a getter or toString(), so it marks the entire containing statement as non-tree-shakeable. This affects all ~416 generated AWS SDK clients.

Solution

This PR changes SchemaTraitWriter.writeTraitsObject() to emit literal string keys instead of computed ones:

// generated output (after)
const _c = "client";
{ "error": _c, "httpError": 400 }

Trait key names are short strings ("error", "httpError", "httpQuery", "streaming", etc.) so the size cost of inlining them is negligible. StringStore abbreviations are preserved for trait values where they continue to save bytes without affecting tree-shaking.

Changes

• SchemaTraitWriter.writeTraitsObject() — format string changed from [%s]: %s, (with stringStore.var()) to "%s": %s, (with shapeId.getName())
• SchemaTraitWriterTest — updated assertion to match new literal key output

[kuhe]

With the availability of other bundlers for optimization-interested applications, and anticipated release of rolldown, I don't want to deoptimize code for esbuild at this time.

We can reevaluate when there is more interest.