[mkatch]

Based on the available options (mostly monospace fonts), it is clear that the "Font Family" setting is intended to control the appearance of code, not the UI chrome around it. This also follows from common sense, as reviewing the code is the primary activity in the app.

However, probably by mistake and low priority, the setting applied to the UI font, so it had very limited utility.

I retired the --app-font-family variable and hardcoded the body styles in the CSS. It is no longer a dynamic style. In its place, I introduced an --mono-font-family that is forwarded to the --font-mono theme variable used across all monospace/code surfaces. The appearance settings panel is bound to this new variable.

Since the setting was used for the UI font, the default value was also proportional/sans while all the other options were mono. I'm guessing this inconsistency is an example of two wrongs that make a right. The default UI font is now exclusively in the CSS and the default value in FONT_FAMILIES is now the tailwind's default --font-mono value.

Many font presets are hardcoded multiple times across the codebase. I considered unifying it into a single source of truth, but eventually decided against it as it was too invasive in this otherwise simple change.

A migration is needed to adapt existing user settings stored in local storage. Upon read, we try to match user's stored setting with one of the pre-defined options. If that fails, we use the default value. This has the following consequences:

• The applied style is always restricted to the predefined values. A legacy value cannot leak into the UI.
• Users who never touched the setting or had it set to default will experience no change.
• User who chose a non-default value will suddenly see its effect in the code. This may be surprising.