chore(sync): reconcile 7c74269 with its merged PR

.sync/nuxt-ui.json

@@ -1453,8 +1453,8 @@
       "summary": "feat(vue): support experimental.componentDetection (nuxt/ui #6731) — PORT of the whole feature plus two defects it surfaced here. Detection scans the app, finds which components are used and narrows the generated theme CSS to those plus their dependency closure; it only ever worked under Nuxt. The mechanism has to differ between the integrations: Nuxt narrows the @source list to the detected components' template files, but the Vue plugin can't, because its templates live inside node_modules where Tailwind widens a file @source to a scan of the whole parent directory — so it sources the whole directory and blanks the theme of undetected components at write time instead (the same transformation theme.unstyled performs; the files still have to exist for the #build aliases and type imports). Scanner fixes in the same commit: kebab-case tags (<b24-button> is mandatory for in-DOM templates and was never matched; the kebab alternative only matches as a tag); prose shadowing (the graph is keyed by basename and eight prose components share one with a regular component, overwriting its dependency set); phantom graph edges and detections filtered against real component files, with unknown includeComponents names now warning; declaration files ignored (components.d.ts declares every component ever rendered, so scanning it kept anything used once detected forever); .mts/.mjs/.cjs added to the scan glob and the dev watcher; and resolveExtraScanDirs, which scans scanPackages packages and components.dirs pointing outside the root, skipping build-output ignores for package dirs since published packages ship code in dist/. Ported in full; the fork's divergences are plumbing — the vue parameter lands fourth rather than fifth on getTemplates and componentDir second rather than third on TemplatePlugin (this fork dropped upstream's unused uiConfig/appConfig threading), Bitrix24UIOptions stops omitting experimental, and utils/components.ts uses consola rather than @nuxt/kit's logger since it must not drag @nuxt/kit into a Vue build. The scan prefix is the literal 'B24' at both call sites (no configurable prefix here) and kebabCase('B24') is 'b24', so <b24-button> and <lazy-b24-tooltip> match — verified, not assumed. Upstream's PageCTA acronym case is n/a: no component here has an acronym in its name. Two defects surfaced: playgrounds/vue/tsconfig.app.json had \"#build/b24ui\" mapped to a value with a wildcard but no wildcard on the key (plus a trailing comma), so TypeScript treated it as an exact match and #build/b24ui/button never resolved — upstream's commit adds the same alias correctly and was taken as the fix; and both installation guides showed componentDetection: ['Modal', 'Dropdown', 'Popover'] where no Dropdown component exists in either project (it is DropdownMenu), which used to be harmless and is not any more now that unknown names warn. One deliberate divergence: the scanned-extension list is exported as COMPONENT_DETECTION_EXTENSIONS and shared between the glob and the watcher, where upstream keeps a literal in each and had to edit both here — an extension in one and not the other means a file that changes the answer never triggers a refresh, with no error and no signal. Tests: upstream's spec adapted, using real temporary directories rather than a mocked fs because half of what is checked is glob and module-resolution behaviour; two tests are this fork's — a graph-edge guard (upstream's spec does not cover that filter, verified by deleting it and watching all 38 tests still pass) and a docs-claims guard for the Dropdown defect; the extension test now iterates the shared constant and a second test holds the glob to it. Ten mutations tried, each red. End-to-end: built playgrounds/vue with detection on — a real test of resolveExtraScanDirs, since its components.dirs points outside the Vite root — and got 43 components detected, color-picker.ts blanked, button.ts not. The CSS saving there is modest and stated as such: 599,544 → 596,929 bytes, about 0.4%, because that app uses 43 components and most of the bundle is shared utilities and design tokens."
     },
     "7c74269387c6ef744b3f05ba5085d4ebcfc41270": {
-      "pr": null,
-      "b24ui_sha": "pending-merge",
+      "pr": 397,
+      "b24ui_sha": "6b7920f97858d81083efe43183da1ddfa1072313",
       "decision": "port",
       "summary": "fix(components): resolve theme props consistently in form controls (nuxt/ui #6834) — PORT of the whole commit plus one fork-specific defect it exposed. useFormField returns size/color/highlight/disabled holding only what the wrapping Form/FormField supplied, so reading one bare drops everything below it in the precedence chain — <Theme :props> and app.config. The correct read is always formFieldX.value ?? props.X against the useComponentProps proxy, and it was done inconsistently: most tv() calls had the fallback, almost no template binding did, and a template binding is where it is invisible, since a ref auto-unwraps there and :disabled=\"disabled\" reads identically whether it is the raw ref or a resolved computed — so controls were painted disabled by a theme without being disabled. Two smaller fixes ride along: Boolean props (Vue auto-casts an unset Boolean to false, so highlight and disabled came back false rather than undefined and the ?? short-circuited before the proxy was read — now normalized back to undefined), and a debounce that outlives the component (emitFormInput's trailing call still fires after teardown, validating a field no longer rendered; guarded with onScopeDispose). The part that makes it stick is a new ESLint rule, no-unresolved-form-field-refs, failing on any read without the fallback, in script and — more strictly — in template, where any appearance at all is reported. Ported in full; the composable had the identical shape here and the rule needed only the bitrix24-ui namespace and B24* names in its messages. The rule drove the rest: rather than replay twenty diffs by hand it went in first and found 69 violations across 19 files — not upstream's list, since this fork has PageCardGroup and Range which upstream does not, and InputRating names its ref formDisabled. All 69 fixed. Two adaptations: inputSize/selectSize keep their names (upstream renames its equivalent to size, shadowing the prop and needing a no-dupe-keys disable; this fork already had a distinct name, so the fallback moved into it and upstream's || → ?? change came with it), and InputRating resolves into isDisabled while keeping its existing disabled computed as the interaction flag, since readonly blocks interaction but only an explicit disabled dims the control. The defect exposed: upstream's own ':props color on a checkbox group reaches its items' test failed here, because CheckboxGroup carried withDefaults(..., { color: 'air-primary' }) — a withDefaults default lands on the raw _props that useFormField receives, so formFieldColor.value was never undefined and the chain could never reach the proxy, making <B24Theme :props> unreachable for that component's colour both before and after this commit. Removed; src/theme/checkbox.ts supplies the same air-primary through defaultVariants, which is the layer the documented precedence puts it in, so default rendering is unchanged and every snapshot passes untouched. It is the only form control in the fork with such a default — checked Checkbox, RadioGroup, Switch, Range, InputRating and Listbox. Theme.spec.ts gains upstream's five cases with assertions grounded in this fork's real output rather than translated by eye, each discriminator read off a real render first. Three mutations tried, each red."
     }