Fix the Flatpak build: keep the icon's <svg> tag in its first 256 bytes

AppStream compose in the Flatpak build failed with "Unrecognized image
file format" for the new scalable icon, so v0.1.5 was never published.
Image loaders recognise an SVG by finding "<svg" within the first 256
bytes, and the icon's descriptive header comment pushed the tag past
that. The comment now lives inside the element; the icon renders
pixel-identically. icons/CMakeLists.txt now fails configuration if the
tag drifts past 256 bytes again. Verified with the KDE 6.10 runtime's
appstreamcli-compose, which now succeeds and emits all catalog icons.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01BxDf7HqD1xPnsZP8wt3NTk

icons/CMakeLists.txt

@@ -4,6 +4,14 @@
 
 # Named after the app ID, as the desktop file, the window icon and Flatpak
 # (which only exports icons prefixed with the app ID) all expect.
+# Image loaders (gdk-pixbuf, and so AppStream compose in the Flatpak build)
+# recognise an SVG by finding "<svg" in its first 256 bytes; past that the
+# file is "Unrecognized image file format" and the Flatpak build fails.
+file(READ sc-apps-io.github.toservetheking.Kareer.svg _kareer_svg_head LIMIT 256)
+if(NOT _kareer_svg_head MATCHES "<svg")
+    message(FATAL_ERROR "icons/sc-apps-io.github.toservetheking.Kareer.svg: the <svg> tag must start within the first 256 bytes; move comments inside the element.")
+endif()
+
 ecm_install_icons(ICONS
     sc-apps-io.github.toservetheking.Kareer.svg
     128-apps-io.github.toservetheking.Kareer.png

icons/sc-apps-io.github.toservetheking.Kareer.svg

@@ -1,13 +1,15 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <!-- SPDX-FileCopyrightText: 2026 ToServeTheKing <[email protected]> -->
 <!-- SPDX-License-Identifier: GPL-3.0-or-later -->
-<!--
-  A K for Kareer, drawn as its application pipeline: the stem is every
-  application, splitting into a success path rising to an outcome and a
-  drop-off falling away. Plain shapes and gradients only, so QtSvg (which
-  ignores filters) renders it exactly as other renderers do.
--->
 <svg width="128" height="128" viewBox="0 0 128 128" xmlns="http://www.w3.org/2000/svg">
+  <!--
+    A K for Kareer, drawn as its application pipeline: the stem is every
+    application, splitting into a success path rising to an outcome and a
+    drop-off falling away. Plain shapes and gradients only, so QtSvg (which
+    ignores filters) renders it exactly as other renderers do.
+  -->
+  <!-- Keep this comment inside <svg>: loaders sniff for "<svg" in the first
+       256 bytes, so a long header comment makes the file unrecognisable. -->
   <defs>
     <linearGradient id="backdrop" x1="0" y1="0" x2="0" y2="1">
       <stop offset="0" stop-color="#4cbcf2"/>