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.

[Lms24]

This fixes a bug which is why I'll approve and merge this, as a pragmatic reaction to this PR. However, @breken-ai or rather to the human who hopefully is reading this: Please do not open such PRs and expect them to be reviewed/merged in the future. The amount of time that goes into these reviews is far greater than the value of fixing a bug that wasn't even reported or actually encountered. To illustrate: The review here consisted of live-testing your change against the current state to see the product implications, checking against our log spec for handling of escape characters, consulting two colleagues, etc. There's a cost to this.
I'm getting paid for this, so it "only" keeps me from the things I should actually work on. Can't imagine what this does to OSS maintainers who maintain this in their free time.

Please file an issue next time, following our issue template.

Also, genuinely curious: Why leave this in draft and then leave it unattended for four days?