fieldMode: 'read' fields render as read-only inputs that are visually indistinguishable from editable ones

Encountered this issue after migrating from an older v6 version to latest v8. You may end up deciding that this is a conscious stylistic choice, but I find it confusing enough to raise it as an issue. It is partially the result of keystar ui design rendering readonly fields differently from the old keystone ui, but since this is related directly to keystone fields I figured that this belongs to this repo.

Repro:

1. Add a field with a read-only item view to any list, eg.:

export const Thing = list({
  access: allowAll,
  fields: {
    name: text(),
    readonlyTest: text({ ui: { itemView: { fieldMode: 'read' } } }),
  },
});

(same result via list-level fieldDefaults.ui.itemView.fieldMode: 'read')

1. Open the item view in the Admin UI.
2. readonlyTest renders as a TextField with the same border, background and text colour as the editable name field. It still shows the hover border and a focus border when clicked into.

The only way to find out the field is read-only is to click into it and try to type.

(In this example it's empty, but even if 'Readonly test' contained some value, it would be styled exactly the same way as the editable 'Name' field, with exactly matching focus states and everything.)

Another good example is the createdAt and modifiedAt timestamps, which also used to be rendered as plain text but are now in readonly inputs which look exactly like the editable ones:

Expected behaviour:

A field in read mode should be visually recognisable as non-editable before the user interacts with it.

In 6.x the item view rendered read-mode fields as plain text (packages/core/src/fields/types/text/views/index.tsx returned value.inner.value inside FieldContainer/FieldLabel when onChange was undefined), which made the distinction obvious. Since the switch to Keystar UI the views instead render the normal input component with isReadOnly but without giving it any visual treatment which results in a read-only field being basically pixel-identical to an editable one.

For further reference, this might be somewhat related to an existing comment in packages/core/src/fields/types/calendarDay/views/index.tsx:

// the read-only date field is deceptively interactive, better to render a
// text field to avoid confusion. when there's no value the field is disabled,
// placeholder text is shown, and the toggle button is hidden
if (!onChange) { ... }

• @keystone-6/core 8.1.0 (currently upgrading from 6.5.3, where read-mode fields used to render as text)
• @keystar/ui 0.10.0
• node v24.12.0
• Chrome (latest)