fix(theme): emit the fixed-theme value with tojson, not a hand-quoted string

[Sunrisepeak]

The bug

Autoescaping applies inside <script> too. The pre-paint bootstrap built its
value by hand as '"' + config.style + '"', so a consumer index setting
theme.style: "dark" got this on every page:

var fixed = "dark";

A classic script is not HTML-parsed, so those entities never decode. It is a
SyntaxError — and a syntax error takes down the entire script element,
not just that line.

Why it is worse than a broken theme

That IIFE does two unrelated things: the pre-paint theme, and the language
redirect. So setting a theming option silently disabled i18n on every
page of the site.

Measured on a consumer index (Sunrisepeak/dsh-index) with style: "dark":

document.documentElement.dataset.theme  ->  "(unset)"
localStorage 'xpi-theme'                ->  null
locale redirect                          ->  never fired

After switching that index back to "auto" (var fixed = null, which parses),
both the theme and the redirect started working again — the redirect landing on
/zh/ was how I confirmed it had been dead.

This is also why it went unnoticed: "auto" is the default and renders null,
so only an index that explicitly pins a theme hits it. xim-pkgindex uses
"auto".

The fix

tojson instead of a hand-quoted string. It emits "dark" / "light" /
null and escapes for a script context, so it fixes the instance and the class.

Test

tests/test_script_escaping.py asserts on the class, not the string:

• scans every inline script in the whole generated site for HTML entities
  that are meaningful in JS (" " ' ' & < >),
  across style = auto / dark / light;
• parses the emitted value with json.loads rather than comparing text, so a
  future change that produces valid-but-wrong JS still fails.

Verified it catches the bug: reverting the template makes 4 of its 6 cases
fail; with the fix, 6 pass.

Full suite: 42 passed.

I also scanned every other {{ }} interpolation inside a <script> in the
templates — this was the only one.