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.:

```ts
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'`)

2. Open the item view in the Admin UI.
3. `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`:

```jsx
// 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)

Start with packages/core/src/fields/types/text/views/index.tsx, where the issue identifies the read-mode rendering, and compare it with the calendarDay view reference in packages/core/src/fields/types/calendarDay/views/index.tsx. Check both field-level and list-level read modes in the Admin UI; done means read-only fields are visibly distinguishable from editable fields while retaining their values and expected interaction behavior.

Written by the indexing model from the issue text.