fix: use UTF-8 for build graph persistence

[ahmedkhan1]

Which issue(s) does this change fix?

Fixes #7714

Why is this change necessary?

BuildGraph uses the locale-default encoding for build.toml. On Windows locales such as CP1252, cached builds with non-ASCII paths fail with UnicodeEncodeError.

How does it address the issue?

Read and write build.toml explicitly as UTF-8, including source-hash updates. Add a regression test that simulates a CP1252 locale and round-trips a Greek code path.

What side effects does this change have?

Existing ASCII build graphs remain valid because ASCII is a subset of UTF-8. Build graphs containing non-ASCII data are now persisted consistently across locales.

Mandatory Checklist

PRs will only be reviewed after checklist is complete

• Review the generative AI contribution guidelines
• Add input/output type hints to new functions/methods (not applicable; no new production functions or methods)
• Write design document if needed (Do I need to write a design document?) (not needed for this targeted bug fix)
• Write/update unit tests
• Write/update integration tests (not needed; covered at the BuildGraph persistence boundary)
• Write/update functional tests if needed (not needed)
• make pr passes (26 unrelated Windows path failures; 7001 unit tests passed and affected tests pass)
• make update-reproducible-reqs if dependencies were changed (not applicable; no dependency changes)
• Write documentation (not needed; no user-facing interface change)

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[reedham-aws]

If an existing file was written with CP1252, would there be a problem that we're now reading it as utf-8? I think the utf-8 encoding would throw an error because it couldn't parse non-ASCII characters (at least according to this Stack Overflow answer).