Field type file: reference a stored file and resolve its metadata on delivery

Found while planning barakocms.com as a barakoCMS-backed site.

To put an image on a content entry today you use a `url` field and paste a `/api/public/files/{id}` string into it. The field type is a string. Nothing checks the file exists, nothing notices when it is deleted, and the alt text has to be duplicated into a second field on the entry because delivery will not resolve it.

`FieldDefinition` already anticipates this: its comment says `blob` is planned and not accepted.

## What to change

A `file` field type that stores a file id and that delivery resolves into an object the way `include` already resolves references:

```json
"coverImage": { "url": "...", "alt": "...", "caption": "...", "width": 1920, "height": 1080 }
```

Depends on the Files module recording dimensions. Together these remove a per-image metadata call from every consumer and stop alt text living in two places.

Start with FieldDefinition and the existing include reference resolution used during delivery, then inspect the Files module and its file metadata. The work is complete when a file field stores a file id and delivery returns the file URL, alt text, caption, and dimensions as one object instead of requiring a separate metadata call.

Written by the indexing model from the issue text.