Fix truncation of compiled theme assets when content contains non-ASCII characters

[wind4gis]

WHY are these changes introduced?

Fixes #0000 (no issue filed yet)
When running shopify theme dev, the locally-generated compiled assets (for example /compiled_assets/styles.css and the compiled scripts) can be unexpectedly truncated when the aggregated content includes non-ASCII characters (for example Chinese/Japanese comments).
Root cause: the server response metadata sets size using JavaScript string.length (UTF-16 code units), but that value is used as a byte-based Content-Length. For multi-byte UTF-8 characters, string.length underestimates the true byte length, so clients stop reading early and the response appears cut off.

WHAT is this pull request doing?

Updates the compiled theme asset handlers to compute response sizes using UTF-8 byte length (Buffer.byteLength(...)) instead of string.length.
Prevents truncated responses for compiled CSS/JS when content contains multi-byte characters.
No functional change for pure ASCII content.

How to test your changes?

Create or use a theme that contains a {% stylesheet %}...{% endstylesheet %} block with non-ASCII characters (for example Chinese comments) in a snippets/ or sections/ .liquid file.
Run the theme dev server:
shopify theme dev --store
Fetch the compiled stylesheet and verify it is not truncated:
curl -s "http://127.0.0.1:9292/compiled_assets/styles.css" | tail -n 50 curl -sI "http://127.0.0.1:9292/compiled_assets/styles.css" | grep -i content-length curl -s "http://127.0.0.1:9292/compiled_assets/styles.css" | wc -c
Repeat for the compiled scripts endpoint (if applicable in your environment) and confirm the response is complete.
(Optional) Remove the non-ASCII characters and confirm behavior remains unchanged.
Expected result: the returned CSS/JS content includes the full output and the Content-Length matches the actual byte size of the response body.

Post-release steps

n/a

Measuring impact

[x] n/a - this doesn't need measurement, e.g. a linting rule or a bug-fix
[ ] Existing analytics will cater for this addition
[ ] PR includes analytics changes to measure impact

Checklist

[x] I've considered possible cross-platform impacts (Mac, Linux, Windows)
[ ] I've considered possible documentation changes

[graygilmore]

This makes sense. Did a little test:

> const basicString = "hello"
undefined
> const emojiString = "hello ✅"
undefined
> const chineseString = "hello 金"
undefined
> [basicString.length, emojiString.length, chineseString.length]
[ 5, 7, 7 ]
> [Buffer.byteLength(basicString), Buffer.byteLength(emojiString), Buffer.byteLength(chineseString)]
[ 5, 9, 9 ]

Thanks for the contribution!

[graygilmore]

@wind4gis please sign the CLA (see the failing CI check).

[graygilmore]

And I think we just need a little rebase to get the graphql-codegen check to pass.

[wind4gis]

@wind4gis please sign the CLA (see the failing CI check).请签署 CLA（见失败的 CI 检查）。

An error occurred, and I'm unable to sign in @graygilmore

[graygilmore]

Please review the error:

Austin <canfeng.huang@narwal.com>: Connect your email address with a GitHub account and sign the CLA to have your PR reviewed

It looks like there are multiple users contributing to this PR.

[github-actions]

This PR seems inactive. If it's still relevant, please add a comment saying so. Otherwise, take no action.
→ If there's no activity within a week, then a bot will automatically close this.
Thanks for helping to improve Shopify's dev tooling and experience.