fix(core): Resolve escape sequences in fmt / parameterize messages

[breken-ai]

parameterize (exported as Sentry.logger.fmt) builds the message with String.raw(strings, ...values), which uses the raw strings. The template it stores uses the cooked strings. So escape sequences in the literal stay as backslash sequences in the message. For example, logger.info(logger.fmt`Line one\nline two ${x}`) sends the log body Line one\nline two ... with a literal backslash-n, and \` or \u2192 come out as typed. Meanwhile sentry.message.template holds the real newline, so the body and the template disagree.

The reverse problem hits a string with an invalid escape sequence, such as a Windows path like fmt`Reading C:\users ${file}`. It has no cooked value, so strings.join turned it into an empty string. The template became just %s, both in sentry.message.template and in the logentry.message that captureMessage sends.

The fix builds both the message and the template from the cooked strings. Where there is no cooked value, it falls back to the raw string. The two new tests fail on develop and pass with this change.

• If you've added code that should be tested, please add tests.
• Ensure your code lints and the test suite passes (yarn lint) & (yarn test).
• Link an issue if there is one related to your pull request. If no issue is linked, one will be auto-generated and linked.

I ran the packages/core vitest suite with and without the change. The only failures are the same 2 environment failures (zoderrrors, typedef) on both. tsc --noEmit on packages/core is clean, and so is oxfmt --check on the changed files. I also ran oxlint on them, without the @sentry/eslint-plugin-sdk JS plugin.

An AI coding agent (Claude Code, run by breken-ai) found this bug and wrote this change. I checked the red/green tests above before opening the PR.

🤖 Generated with Claude Code