Implement debounce on high-frequency form inputs

Nobody has claimed this yet.

Currently, every interaction with keyboard entry fields (text, number) and slider inputs triggers a `valueChanged` signal. This signal invokes `recalculateDerivedItems` within the `AttributeController`, causing a full form recalculation. In complex schemas, this high-frequency recalculation leads to unnecessary CPU overhead and potential UI stutters.

**Let's do this**
Introduce a debounce mechanism to delay the execution of form recalculations until the user has paused their input. This will optimize performance while maintaining a responsive user interface.

We must balance performance gains against "perceived lag":
- Visibility Logic: Visibility of tabs or groups dependent on these fields must feel instantaneous. If the debounce threshold is too high, the UI will feel "mushy."
- Constraint Validation: Users rely on immediate feedback for Not Null violations or range constraints. We need to find the "Goldilocks zone" (suggested starting point: 250ms–300ms).
- Immediate Commit (optional): We might consider immediate execution (skip debounce) on events like keyboard is closed or enter/tab is pressed

**Acceptance Criteria**
- Performance: High-frequency typing in a text field does not trigger form recalculation on every keystroke.
- Responsiveness: Derived fields, constraints, groups and tabs update/react _promptly_ after input ceases
- (optional, if we need to implement this) Switching focus or hitting "Enter" bypasses the debounce and triggers an immediate recalculation.

Related to #4290

Start by locating AttributeController and the recalculateDerivedItems entry point, then trace how keyboard, number, and slider valueChanged signals reach it. Define and validate a debounce interval around the suggested 250–300ms, ensuring derived fields, constraints, groups, and tabs update promptly after input stops and checking whether focus changes or Enter require immediate recalculation.

Written by the indexing model from the issue text.