[Feature request] readOnly state for Input, Textarea, and Number/Password/Date inputs (distinct from disabled)

[MontseTelefonica]

Currently, these components only document Default, Disabled, and Invalid states. There is no read-only state, and no readOnly prop is mentioned in any of their FAQs.

Requested change:

• Add a readOnly boolean prop, distinct from disabled, to the components built directly on the native <input>/<textarea> element: Input, Textarea, Number input, Password input, and the text field portion of Date input.
• All of these map directly to the native HTML readonly attribute, and React Aria's useTextField already supports isReadOnly at the primitive level. This should be a low-effort, consistent change across components that already share the same underlying primitive — not a new interaction pattern.
• The read-only visual treatment should differ from disabled: it should clearly show a valid, current value (not a greyed-out, inactive-looking field).
• Out of scope for this request: Checkbox, Radio, Toggle, Slider, Select, Multi-select, and Tag input have no native readonly attribute in HTML, so a read-only state there would need a custom ARIA pattern and extra interaction-blocking logic rather than reusing an existing primitive. Leaving those out keeps this request scoped to a small, mechanical change.

Why this should not just reuse the disabled state (accessibility rationale):

1. Focusability/discoverability — disabled removes the field from the tab sequence entirely. Keyboard-only and screen reader users tabbing through the form will skip it and may never encounter the value. A read-only field stays focusable, so its label and value are announced in the natural tab order.
2. Correct semantics for assistive technology — screen readers typically announce "read only" for a readonly field, correctly communicating why the value cannot change. disabled instead implies "inactive/not applicable," which misrepresents a valid, current value. This maps to WCAG 4.1.2 (Name, Role, Value): the exposed state should match the field's actual condition.
3. Form submission — browsers exclude disabled fields from form submission by default. If the value needs to travel with the rest of the form data, disabled silently drops it, while readOnly keeps it in the submitted payload.
4. Copy/select support — users may need to select and copy a read-only value. disabled fields are not selectable via keyboard in most browsers; readOnly fields are.

Use case (illustrative): A profile settings form where one field's value is managed by an external identity provider (SSO), with helper text explaining the value must be changed elsewhere. The field must still display its current value, remain focusable, and be understood by assistive technology as "read only," not "disabled."