Content types: change a field (rename, convert, remove) through one endpoint, applied by a job

No endpoint changes a field once it exists. The add field endpoint says so: `barakoCMS/Features/ContentType/AddField/Endpoint.cs:70`. The routes that touch an existing type add a field, add SEO fields, change sensitivity or toggle delivery. The only route that replaces fields is Portability import, which swaps the whole list with no checks (filed as a bug, #933). Sensitivity changes rebuild `SearchText` in batches of 200 inside the HTTP request (`barakoCMS/Features/ContentType/SetFieldSensitivity/Endpoint.cs:55`, `:237`), so a large type holds the request open for the whole rebuild.

### Why it is too specific

Adding is the only change the model supports. A clinic renaming `Doctor` to `Practitioner`, a school converting `Grade` from a string to a choice (#803), or a bakery removing a field it stopped using has to create a new type and move entries by hand. Planned work writes into field definitions too: field roles (#887), choice options (#820), computed fields (#836), locale (#98) and config apply (#345). Each would add its own partial edit path.

### The general concept

One endpoint changes a field, and each change is classified: additive (label, description), rename, convert (a type change with a declared mapping), or destructive (remove, or a convert that loses data). A change that touches entries runs as a job whose partial run is visible and resumable, as D8 requires. A destructive change is refused without an explicit flag, and the refusal names how many entries hold a value. Schema backfills, the sensitivity search text rebuild included, move to the same job runner and keep the order that endpoint depends on: when raising, the rebuild finishes before the definition changes.

### Where it lives

Core: content type features and Jobs (`barakoCMS/Infrastructure/Jobs`).

### Compatibility

Released, and it changes stored entry data, so each applied change is a migration of that type's entries. The new endpoint is additive. The sensitivity endpoint keeps its route and response; if its rebuild becomes a job, the job reference is an added field. A renamed field is still read under its old key until the job completes.

### Done when

- Renaming a field on a type with entries moves every entry's value to the new name through a job, with a test that fails before the change.
- Removing a field without the destructive flag is refused with the count of entries holding a value.
- A job stopped partway reports its progress, and running it again finishes the change.

Relates #345, #709.

Found in the architecture sweep of 15 September 2026.

Start by reading barakoCMS/Features/ContentType/AddField/Endpoint.cs:70 and SetFieldSensitivity/Endpoint.cs:55, :237, then inspect the Jobs area in barakoCMS/Infrastructure/Jobs. Trace how field definitions, entry values, and the existing sensitivity rebuild are handled. Done means a resumable job supports rename and guarded removal, reports progress, and preserves the stated compatibility behavior.

Written by the indexing model from the issue text.