chore(sync): reconcile the 14ac2438 entry with #443

.sync/nuxt-ui.json

@@ -1567,8 +1567,8 @@
       "summary": "docs(showcase): add triadtrainer.vercel.app (nuxt/ui) — NO-OP: two lines in docs/content/showcase.yml plus a screenshot asset, adding triadtrainer.vercel.app to the list of sites built with Nuxt UI. We have that file, but it lists projects built with Bitrix24 UI and its own description says so, so adding a nuxt/ui site would make the page assert something false. Content, not structure — nothing to port and nothing to adapt. Same call as cf5f15e3 and f6d188bd; recorded so the next porter does not re-derive it a fourth time."
     },
     "14ac243804bc02c6c1226823d1da3092cfcc9df3": {
-      "pr": "pending-merge",
-      "b24ui_sha": "pending-merge",
+      "pr": 443,
+      "b24ui_sha": "367cbf5ea17ecb8a1ceefb3da120eb3d5ea50e8c",
       "decision": "port",
       "summary": "feat(ProgressGroup): new component (nuxt/ui #6860) — PORT of both halves, minus one feature declined by decision. 26 files doing two things: a new ProgressGroup (bar split into segments with their own values and colours, plus a legend) and three changes to the existing Progress. HALF ONE, which stands alone: Progress's statusStyle wrote the size inline, so an inline style beat any class and b24ui.status could not change it — the override was accepted and silently ignored. It moves to a CSS variable the theme reads (w-(--percent) horizontal, h-(--percent) vertical, with transition-[width]/[height] moved out of the base slot). This fork's statusStyle was NOT upstream's: ours falls back to fit-content when there is no percent and upstream has no fallback; it survives because w-(--percent) emits width: var(--percent) whatever the value, but nothing tested it, so a 'with status at zero' case is new and mutation-verified (replacing the fallback with ${percent ?? 0}% fails that case and only that case). Also took the note pointing Progress at ProgressGroup and the tip about :b24ui={ status: 'w-full' }, which is exactly what the --percent change makes possible. HALF TWO, the component, adopted by maintainer decision as with Splitter. The colour mechanism is a real adaptation rather than a translation: upstream colours the indicator directly with bg-${color}, while here a colour is a style-* class defining --b24ui-background that the indicator reads, and Progress puts that class on root. A group needs a colour per segment, so the class moves down one level — onto segment, itemLeadingDot and itemLeadingIcon, each reading the variable it defines. Checked in rendered output, not source: segment carries style-filled-alert, indicator carries bg-(--b24ui-background), the dot carries both. DECLINED by decision: arbitrary CSS colours — upstream widens color to (string & {}) and applies an off-palette value inline; removed here along with the themeColors/customColors computeds, the progress.md tip and ProgressGroupCustomColorExample, because the mechanism keys off bg-${color} on the indicator which is not how this fork colours anything, and (string & {}) for a colour would be the library's first (the pattern exists only for target, rel and slot names). UIcon becomes <Component :is=\"item.icon\"> and IconProps['name'] becomes IconComponent. One difference a reader will notice: the leading icon renders data-slot=\"icon\", not data-slot=\"itemLeadingIcon\" — b24icons set that on their own root and shadow whatever is passed, uniformly across the fork (6672 occurrences in the snapshots, zero component-specific icon slots, Accordion included); the class still arrives, which is what carries the colour. Not ported: the preview PNGs (no such grid here) and ComponentProps.vue/ComponentPropsSchema.vue, which carry upstream's docs plumbing for the (string & {}) colour type. Verified: dev:prepare across all four apps, lint, typecheck, test (6790 passed, 6 skipped, 298 files), build, docs:generate — all green; 52 snapshots for ProgressGroup, 8 moved for Progress, and docs:generate prerenders 1255 routes against 1248, so the page and its two examples build."
     }