feat(webpanel): compare running artifact against recommended build

[jhag01]

Description

Closes #85

The server status card showed the running artifact and the recommended one as
two plain rows, leaving the reader to diff two five-digit build numbers by eye,
and printing the same number twice whenever they matched.

Both builds now go through a compareArtifactBuilds helper, and the card renders
a single status strip in place of the second row:

State	Strip
running behind	⬆ b35945 recommended, primary accent, links to the artifact source
matches	✓ Up to date, muted
ahead of recommended	ⓘ Ahead of b35945, muted
either build unknown	no strip

The primary accent is reserved for the one state that asks the admin to act, so
the sidebar stays quiet when nothing needs doing and the card keeps a single
green in the Status: running badge. Dropping the separate "Recommended" row
removes the duplicate number.

How it's put together

• lib/artifact-version.ts - compareArtifactBuilds(current, recommended)
  returning 'outdated' | 'current' | 'ahead' | 'unknown'. Pure, with unit
  tests, following the same extract-the-logic pattern as perf-series and
  session-expiry.
• static/artifact-state.tsx - per-state icon, tone and wording, following the
  STATUS_VARIANT precedent in static/server-state.ts. Typed as
  Record<Exclude<ArtifactStatus, 'unknown'>, …> so adding a state to the union
  fails to compile until the map is updated.
• components/sidebar/server-status.tsx - picks the entry and renders one strip.

Comparison is numeric rather than lexicographic ("9999" sorts after "13068"
as a string), and both sides are validated against the same 4-8 digit shape
parseFxServerBuild produces. Anything else yields 'unknown' and renders no
strip, so a failed jgscripts lookup or an unreadable convar never produces a
confident wrong answer.

No new dependencies, no API changes, no migrations.

Generative AI Disclosure

• No, Generative AI was not used in the creation of this PR.
• Yes, Generative AI was used in the creation of this PR.
  • Tools used: Claude Code (Opus 5)
  • Purpose / What it was used for: The feature, the behaviour it should
    have and the design calls along the way are mine. Claude did the work of
    fitting that into this codebase - writing the comparison helper and its unit
    tests, the presentation map, the JSX changes, and this description, and
    matching the existing conventions while doing it.

---

Tests

• Tested in development mode
• Passes typecheck
• Builds & runs on Windows
• Builds & runs on Linux

---

Additional Notes

On the testing boxes, precisely:

• Verified against a live FXServer by building the Windows binary and running it
  against a real server rather than via bun dev. Both the outdated and
  up-to-date strips were confirmed rendering in the real sidebar.
• bun run typecheck passes across all 6 packages; bun run test passes
  (73 files).
• The Linux binary compiles (bun run build --target=linux), but I have no
  Linux host to run it on, so I've left that box unchecked rather than claim it.
  The change is webpanel-only and platform-independent, so I'd be surprised by a
  difference, but I haven't verified it.

Unrelated observation, not addressed here: useRecommendedArtifact fetches
once per mount with [] deps, and the sidebar sits in AppLayout, which
react-router keeps mounted across navigation. The recommended build therefore
only refreshes on a full page reload, which limits how much the 30-minute
server-side TTL matters for a long-lived tab. Happy to open a separate issue if
that's worth changing.

---

On this write-up: drafted and tidied up with Claude, so the reasoning and
trade-offs are all laid out in one place.

[Maximus7474]

Thank you for the contribution, this does properly address the described issue.
In future, you don't need to create an issue if you've already drafted a PR which also covers in the same amount of detail the addressed issue, as it leads to unnecessary repetitions.