fix(settings): quote the chosen font family so odd names still apply

[PathGao]

What this is

A font family picked in settings now reaches CSS quoted, so a name that is not a
bare CSS identifier applies instead of being silently discarded. Found while
working on #810, where @felhasznalonev reported that fonts activated by a
third-party font manager appear in the dropdown and do not load. This does not
close that issue — whether it is his case depends on the font's name, which I
have asked for there.

Mechanism

MarkdownViewer.svelte interpolated the name bare — font-family: {settings.previewFont}, sans-serif — and editorOptions.ts handed the raw
string to Monaco. That is valid CSS only while the name happens to be a
sequence of identifiers. M+ 1c, 04b03, Gill Sans (Body): each makes the
whole declaration invalid, so the browser drops it and the element keeps the
font it inherited. Nothing fails loudly — the family is in the dropdown,
selecting it changes nothing, and the user cannot tell that apart from the font
not being installed.

Measured in a WKWebView, parent element at 40px Courier:

font-family: Helvetica, sans-serif          -> Helvetica   257.66px
font-family: M+ 1c, sans-serif              -> Courier     264.04px   declaration dropped
font-family: 04b03, sans-serif              -> Courier     264.04px   declaration dropped
font-family: Gill Sans (Body), sans-serif   -> Courier     264.04px   declaration dropped
font-family: Helvetica!, sans-serif         -> Courier     264.04px   declaration dropped
(no font-family at all)                     -> Courier     264.04px

font-family: 'M+ 1c', sans-serif            -> sans-serif  257.66px   survives
font-family: '04b03', sans-serif            -> sans-serif  257.66px   survives
font-family: 'Gill Sans (Body)', sans-serif -> sans-serif  257.66px   survives
font-family: 'Helvetica!', sans-serif       -> sans-serif  257.66px   survives

Monaco is not a second implementation of this. BareFontInfo._wrapInQuotes
quotes a family only when it carries a space or a +, so 04b03 still reached
the stylesheet bare, and it skips its own quoting entirely once the value
contains a quote character — which is what lets this one stand in front of it.

The two other cases fontFamilyValue covers: the CSS generics stay unquoted,
because "sans-serif" is a request for a family nobody has and because
defaultFontsFor('linux') picks Monospace and system-ui; and a blank
preference returns the fallback alone, since stringSetting applies any
non-null raw value and an empty preview.font key used to produce
font-family: , sans-serif, invalid like the rest.

Scope

Only the two places a chosen family reaches CSS. Not touched:

• The export and print paths, which do not write font-family themselves.
• The static var(--win-font) families in the components, which are not user
  input.
• The font list. get_system_fonts enumerates families through font_kit
  and that half works — the reporter's font was listed.
• Whether a font file kept only in a cloud folder can be read at all. It can:
  a WKWebView here rendered a family that a separate process had registered
  from a non-standard directory with CTFontManagerRegisterFontsForURL at
  session scope, and the shipped 2.7.6 bundle carries no entitlements, so there
  is no App Sandbox gate to fail. That rules out the explanation I first gave
  in Paragraph, icon, fonts, settings, sidebar, highlight #810; it does not yet explain his case.

Tests

scripts/fontFamily.test.ts, new: the quoting and escaping, the generics, the
blank preference, and two source-shape assertions that both call sites go
through the helper. Reverting the two call sites and keeping the test goes red
on the shape test; the behaviour assertions run the helper and pass either way,
which is why the shape half is there.

The shape half is an absence claim as much as a presence one —
assert.doesNotMatch(viewerSource, /font-family: \{settings\./) — because a
second bare interpolation is the defect returning and running the helper that
does exist cannot observe one.

scripts/editorOptionWiring.test.ts: one fixture now spreads the full
SETTINGS instead of the single setting under test. It passed a stub with no
editorFont, which editorOptionsFromSettings did not read before and does
now — a string field arriving as undefined, a shape the type forbids and
production cannot hand it.

Verification

npm run check       840 files, 0 errors, 0 warnings
npm test            1033 pass, 0 fail
npm run test:vitest 445 pass, 51 files

No Rust changed, so cargo test / clippy / fmt were left to CI. Not
verified: Windows and Linux, and the reporter's own font — the numbers above are
a WKWebView on macOS 27 with names chosen to reproduce the parse failure, not
his install. A macOS test build is on my desktop for a run against a real
awkwardly-named font before this merges.