fix(frontend): block invalid step names instead of only warning

[Bhavd33p]

Summary

• Input.tsx's handleChange called updateValue() unconditionally, regardless of whether the typed value failed the regex/maxLength/onBeforeUpdate validation. For the pipeline-step-name field this meant a name like add-strings got saved into the notebook cell metadata (and could be selected as a dependency by other steps) even though it's invalid — it would only fail later, at pipeline compile time, with a confusing error, since step names are spliced into the generated code as Python function/variable identifiers (so hyphens can't be allowed there, unlike pipeline names which follow DNS-1123 naming and do allow hyphens).
• Input now tracks the field's live text in local state, separate from the committed value passed via updateValue. Invalid text still renders in the field with the existing red error styling/message (so users can see and fix it), but it's never propagated to updateValue/notebook metadata. This also incidentally fixes the same class of bug for duplicate step names (the onBeforeUpdate check), which had the identical problem.
• Reworded STEP_NAME_ERROR_MSG to explain why hyphens aren't allowed for step names (unlike pipeline names), instead of just stating the rule.

Fixes #882

Test plan

• tsc --noEmit, eslint:check, prettier:check all pass.
• jest passes (no labextension component tests exist yet in this repo to extend).
• Manually verified in a running JupyterLab + Kale sidebar: typing a hyphenated step name (e.g. add-strings) now shows the reworded error message live and is never committed (no tag chip appears above the cell, confirmed against the notebook's actual cell metadata). Fixing it to a valid name (e.g. add_strings) commits normally and shows the step chip.

[google-oss-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign jesuino for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[harshhh817]

Read through this one — the fix looks right to me, and the local-state split is the correct shape: the field keeps showing the invalid text (with the error styling) while never letting it reach updateValue, so the user isn't fighting the input.

Since Input is shared, I checked the other consumers to make sure nothing regressed:

consumer	passes regex / maxLength?	effect
GpuSection, BaseImageSection, AnnotationInput	no	unaffected — isRegexValid/isMaxLengthValid short-circuit to true
CellMetadataEditor (step name)	yes	the case this PR fixes
ExperimentInput	yes (^[a-z]([-a-z0-9]*[a-z0-9])?$)	see below

ExperimentInput is the one that changes behaviour beyond step names, and it seems fine: that DNS-1123 pattern rejects a trailing hyphen, so typing my- mid-word is now not committed. The field still displays my- with the error, and the commit lands as soon as it becomes valid again — the fallback is the last valid value rather than a partially-invalid one, which is the same guarantee you're adding for step names. Worth a second opinion from someone who knows the experiment flow better, but I couldn't construct a case where it loses data.

The useEffect resync on propsValue also covers the external-update path (switching cells, metadata reloaded underneath), which was the thing I most expected to break with local state.

Nice touch reworking STEP_NAME_ERROR_MSG to say why hyphens are rejected — "becomes a Python identifier" is the part that actually stops someone retrying.

Non-binding LGTM (not a maintainer).