fix(workflow-form): the read-only input card blocks the pointer but not the keyboard #8758

What happened?

The Form View's read-only input card locks itself with pointer-events: none (workflow-form.component.scss:340, applied by [class.read-only]="!canEdit" at workflow-form.component.html:232). That only blocks pointing-device hit testing. A keyboard user can Tab into a custom widget's own controls inside the card -- a file picker's Browse button, the HuggingFace file input -- and activate them with Enter or Space. The bound formly controls are disabled through props.disabled, but the controls a widget draws of its own do not consult the form's disabled state: the HuggingFace audio input, for one, POSTs the selected file.

Expected: read-only blocks keyboard interaction as well as pointer. The step panel already does this with inert for the same reason (workflow-form.component.html:484, [attr.inert]="panelLive ? null : ''"); the input card should follow.

Part of #8439 (item 5) and the Form View feature #8011. Raised by Copilot on #8437, #8438 and #8440.

How to reproduce?

1. Open a workflow that exposes a HuggingFace audio (file) input in the Form View, as a user without write access (the card is read-only).
2. Press Tab until the focus lands on the widget's file input or Browse button inside the card.
3. Press Enter or Space and choose a file.
4. The upload request goes out although the card is read-only.

Fix sketch: put inert on the read-only card, giving the container tabindex="-1" and an aria-label so keyboard users can still scroll it (the step panel's precedent), or disable every descendant control semantically. A DOM test that focuses a widget control inside a read-only card and asserts it can be neither focused nor activated.

Version/Branch

1.4.0-incubating-SNAPSHOT (main)

Commit Hash (Optional)

506397a

What browsers are you seeing the problem on?

Chrome

Relevant log output

No response