fix(studio): strip color-font glyphs from READMEs on Linux

[InfoSage05]

Summary

Opening the Model Hub tab freezes the app on the Linux "Complete" AppImage (0_1_801_beta), requiring a force-quit. The console shows a Skia assertion failure in colrv1_configure_skpaint -> which is an out-of-bounds vector access while rendering a COLRv1 color font glyph (plain emoji/flags). This regressed after #9113 switched the Linux AppImage from the host's own WebKitGTK to one bundled from the build machine, replacing whichever (working) WebKitGTK/Skia build each user's distro shipped with one specific build that appears to carry this bug.

The Model Hub tab auto-previews the first row's README as soon as it opens (split view). READMEs are arbitrary Hugging Face markdown and routinely contain emoji/flags where it exactly what triggers the crash. This PR strips color-font-triggering characters (pictographs, regional-indicator flag pairs, VS-16, ZWJ, skin-tone modifiers, flag tag characters) from README content before it reaches the renderer, gated to Linux only so Mac/Windows keep rendering emoji as before.

Root Cause

The root cause is the Linux Complete AppImage's bundled WebKitGTK/Skia build asserting on a COLRv1 color-stop table (colrv1_configure_skpaint, studio/src-tauri packaging from #9113) when the Model Hub tab's auto-previewed README (studio/frontend/src/features/hub/catalog/model-readme.tsx) renders ordinary emoji/flag characters from Hugging Face model card content.

Changes

• studio/frontend/src/features/hub/lib/color-font-triggers.ts (new): pure stripColorFontTriggers() —> strips \p{Extended_Pictographic}, \p{Regional_Indicator} (flag pairs), \p{Emoji_Modifier} (skin tones), VS-16, ZWJ, and flag tag characters. Kept dependency-free (no @/-aliased imports) so it is directly unit-testable.
• studio/frontend/src/features/hub/catalog/model-readme.tsx: prepareReadmeBody() now calls stripColorFontTriggers() on the README body, gated to usePlatformStore.getState().deviceType === "linux" only.
• studio/frontend/tests/hub-readme-color-font.test.ts (new): unit tests covering a plain pictograph emoji, a regional-indicator flag pair, a ZWJ family sequence, a VS-16 star/checkmark, and confirming plain markdown/code/links/arrows are left untouched.

Reproduction

Reported in #9453: on the Linux Complete AppImage (0_1_801_beta), opening the Model Hub tab freezes the app; only force-quit recovers. Console shows:

colrv1_configure_skpaint(...): Assertion '__n < this->size()' failed

Not independently reproduced in this environment (no Linux AppImage available here) and hence the fix targets the concrete, evidence-backed trigger (arbitrary emoji/flags in HF README content reaching a known-buggy bundled Skia build), verified via full frontend typecheck/build/test rather than an on-device repro.

Testing

npm run typecheck   # tsc -b, clean
npm run build       # vite build, succeeds (pre-existing chunk-size warnings only, unrelated)
npm test            # node --test, 4258/4258 pass including the 5 new cases

Checklist

• Tests added
• All existing tests pass (4258/4258)
• Typecheck passes (npm run typecheck)
• Build passes (npm run build)
• Lint passes on changed/new files (npx eslint ...)
• Linked to the issue (Fixes #9453)

Fixes #9453

[InfoSage05]

@danielhanchen please have a look at this!

[danielhanchen]

Confirmed the strip hooks into prepareReadmeBody in studio/frontend/src/features/hub/catalog/model-readme.tsx, and the reported assert comes from the AppImage's bundled Skia. This branch also carries the PaddleOCR registry and example additions, so could you split those out and keep the strip scoped to the AppImage rather than all Linux, since a distro WebKitGTK renders these glyphs fine?

[InfoSage05]

Thanks for the review! I've updated the branch with the requested changes:

1. Split out unrelated additions: Rebased cleanly onto main and removed the PaddleOCR registry and example commits from this branch so the PR is strictly focused
   on the README color-font fix.

2. Scoped strip to Complete Linux AppImage:
   - Backend: Added is_appimage to the authenticated /api/health response (checking the APPIMAGE environment variable).
   - Frontend: Added isAppImage to usePlatformStore via env.ts.
   - README parser: Updated prepareReadmeBody in model-readme.tsx to gate stripColorFontTriggers() specifically on usePlatformStore.getState().isAppImage
   instead of deviceType === "linux", so distro-packaged WebKitGTK installations continue to render color glyphs untouched.

3. Tests & Linting:
   - Added backend tests in studio/backend/tests/test_health_reports_appimage.py verifying is_appimage reporting and auth gating.
   - Verified studio/frontend/tests/hub-readme-color-font.test.ts (all 5 test cases passing).
   - Cleaned up intra-feature imports in model-readme.tsx to satisfy ESLint; all TypeScript compilation checks and the full test suite pass cleanly.

[danielhanchen]

Confirmed prepareReadmeBody in studio/frontend/src/features/hub/catalog/model-readme.tsx still passes raw README markdown straight through, so the Linux path from #9453 is untouched today. This branch also adds the PaddleOCR-VL example and registry entries, which are unrelated to the freeze, so could you split those out and leave just the hub README change here?

[danielhanchen]

The README strip in studio/frontend/src/features/hub/catalog/model-readme.tsx is keyed on deviceType === "linux", so every Linux install loses emoji in model cards even where the renderer is fine, and the branch also carries the PaddleOCR-VL registry and example. Could you narrow the gate to the affected bundled runtime and split the PaddleOCR work into its own PR?

[danielhanchen]

Main now avoids this crash in the Linux AppImage by bundling a CBDT emoji font and rejecting host COLRv1 fonts in studio/src-tauri/linux/appimage-fonts.conf (via #9473), so I do not think the README stripping is needed any more. Sorry for the slow review, and thanks for putting it together.