Feature: open a fresh install on the Midnight Ramen background

[DevMando]

Summary

Adds a fourth background to the box — Midnight Ramen — and makes it the image a brand-new
install opens on, replacing Golden Gate as the app's first impression. The three existing
backgrounds all stay in the gallery, one position further down.

This is the background that marks the 0.15.0 release.

Why this matters

A fresh install already opens on a background rather than a bare theme, which is what makes the
gallery discoverable at all. But the default has been a landscape photograph since the feature
shipped, and it does not say much about what the app is. The new image does, and a release is the
right moment to change the thing every new user sees first.

What changed

• A new bundled background. 01-midnight-ramen.jpg — 1536×1024, 485 KB, within the folder's
  600 KB budget. Dark with warm highlights, which is what a backdrop sitting at 30% opacity behind
  a conversation needs to be.
• The gallery is renumbered so the new image leads it. Golden Gate, Sequoia Trail, and Pismo
  Beach become 02-, 03-, and 04-. Nothing is removed.
• No code change. BuiltInBackgrounds discovers the folder at startup and the csproj globs it
  by extension, so adding an image is a file drop. The NN- prefix already both orders the gallery
  and selects the first-run default, so renumbering is the whole mechanism.

Scope and risk

Low, but with one behaviour worth a reviewer's attention.

The file name is the durable identity persisted in ui-settings.json, so renaming the three
existing images has a visible consequence for existing users. Who is affected, precisely:

User	Effect
Picked a built-in tile	Background keeps working; its tile may stop showing as selected in Appearance until re-picked
Picked their own file	No effect at all — ChatBgBuiltIn is null, and there is no tile to un-mark
Chose no background	No effect
Never launched the app	Opens on Midnight Ramen — the intent

No one loses a background. Selecting anything copies it into %LOCALAPPDATA%\MandoCode.Desktop
as chat-bg.<ext>, and that copy is what renders — the install folder is only ever a copy source,
so nothing in this PR can reach an existing user's active image.

Existing installs cannot be re-skinned: ThemeManager.Initialize guards the first-run path on a
missing settings file, and the method writes that file unconditionally, so anyone who has launched
the app once is permanently past it.

One pre-existing behaviour this makes visible: CopyToOutputDirectory copies but never
deletes, so a build output — or an install folder that a new release is extracted over — keeps
the old file names alongside the new ones and shows duplicate tiles. The documented install is
"extract it anywhere", and winget's portable package uses a per-version directory, so neither
normal path hits this. It is cosmetic where it does occur and cannot affect anyone's active
background. Flagging it rather than working around it, but happy to add a cleanup step if you
would rather not ship the sharp edge.

Verification

• dotnet build src/MandoCode.Desktop — succeeded, 0 warnings, 0 errors.
• dotnet test src/MandoCode.Desktop.Tests — 489 passed, 0 failed. This includes
  BuiltInBackgroundsTests, which pins the naming convention this change depends on: ordering by
  numeric prefix, prefix stripping for display names, and the file name as durable identity.
• Confirmed the renamed files are picked up by the csproj glob and land in the build output.
• Inspected the encoded JPEG directly to confirm the transcode from the source PNG is clean.

Not covered: the first-run path itself is not under automated test — it depends on a missing
%LOCALAPPDATA% settings file, so verifying it means launching with that folder cleared. Worth a
manual check before the release tag. The duplicate-tile case described above was observed in a
local incremental build, not in a published output.