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!