Refactor Knob component styles for performance

[MaddipatlaChetan24]

Fixes #1, Fixes #2

Description

Refactors two style overrides in the Knob component to use static,
module-level objects instead of inline object/function literals that
were being re-created on every render.

• RadioGroupRoot's style was written as a function
  (({ $theme }) => ({...})) but never actually referenced $theme in
  its return value — it was a constant disguised as a function. Replaced
  with a plain module-level RADIO_GROUP_ROOT_OVERRIDE_STYLE object,
  which baseui's overrides.<Component>.style accepts directly. This
  removes both the per-render function allocation and the function call
  baseui previously had to make to resolve it.
• The Checkbox's Label override (style: { fontWeight: 500 }) was
  already a static shape but was being re-allocated as a new object
  literal on every render. Hoisted to a module-level
  CHECKBOX_LABEL_OVERRIDE_STYLE constant so the same object reference
  is reused across renders.

Both changes are behavior-identical — same resolved styles, same visual
output — just without the unnecessary re-allocation.

Left the two per-Radio overrides inside the enum options .map()
unchanged. They do use $theme and can't become plain objects, and
while they could in principle also be hoisted to module scope, doing so
risks losing baseui's contextual type inference for the $theme
parameter (which is currently inferred from the JSX prop's expected
type) and could introduce a type error without knowing this project's
exact tsconfig/baseui override type setup. Flagging as a possible
follow-up rather than guessing at a fix that might not compile.

Scope

Patch: Bug Fix

[MaddipatlaChetan24]

can you please check this !!

[dyesin]

Thanks for the PR. Before we review it, please note that "check this" isn't a submission we can accept. It hands the verification work to maintainers, and our review time is limited.

We welcome AI-assisted contributions, but you are the author and must stand behind every line. Before requesting review, please:

Run it. Set up the dev environment, run the full test suite, and confirm the change works as intended.
Understand it. Be ready to explain why each change was made and what could break. "The model suggested it" isn't an answer.
Justify it. Describe the actual problem this solves and how you confirmed it's fixed. For performance changes, include evidence.
Test it. Add or update tests following the patterns already used in the repo.
Keep it focused. One concern per PR, with no unrelated edits.

Once you can confirm all of the above in the PR description, we're happy to take a look. Until then, we'll mark this as a draft.