[diegosouzapw]

Regression

Lote 2b (#17416) passes indeterminate={…} to the shared Checkbox adapter (src/shared/components/Checkbox.tsx) at two sites in ConnectionsListPanel.tsx. It works at runtime: the adapter spreads ...props to the kit Checkbox, which supports indeterminate and applies it to the input through a ref. The adapter's prop type did not declare it, though, so check:dashboard-typecheck reported a new TS2322 and went red for every lote:

✗ src/app/(dashboard)/dashboard/providers/[id]/components/ConnectionsListPanel.tsx TS2322 (baseline 3, live 4)

Fix

• CheckboxProps now declares indeterminate?: boolean.
• The adapter passes it to KitCheckbox explicitly. It is still forwardRef, it still imports the kit from the @omniroute/ui-kit/checkbox subpath, and every existing prop and behaviour is unchanged.
• ConnectionsListPanel.tsx and the typecheck baseline are untouched.

Dashboard typecheck

• Before: [dashboard-typecheck] FAIL with ConnectionsListPanel.tsx TS2322 (baseline 3, live 4)
• After: [dashboard-typecheck] OK — 194 pre-existing error(s), all within frozen baseline. with ConnectionsListPanel.tsx TS2322 (baseline 3 -> live 2). The baseline file is untouched; ratcheting it down is left to the controller.

Also run: npm run typecheck:core (exit 0), plus eslint and prettier --check on the two changed files (clean). The vitest run over the adapter test, datatable.test.tsx and selectAllIndeterminate.test.tsx passed: 3 files, 12 tests.

Test

New case in tests/unit/ui/adapters/textarea-checkbox.test.tsx. The kit does not emit aria-checked or data-state; it sets the DOM indeterminate property. The test therefore checks input.indeterminate === true and :indeterminate, re-renders with indeterminate={false}, and checks that both flip back. The runtime spread already carried the prop, so the type error caught by tsc is the red signal; the DOM test pins the forwarding.

⚠️ base-red inherited: #17219