utils-testing: drop the blanket cast on dotcmsContentTypeBasicMock and fix the fixture drift it hides

Task

Remove the blanket as unknown as DotCMSContentType from dotcmsContentTypeBasicMock in libs/utils-testing, and fix the fixture drift it hides.

Context

libs/utils-testing/src/lib/dot-content-types.mock.ts:

export const dotcmsContentTypeBasicMock = {
    baseType: null,
    clazz: null,
    description: null,
    // …some twenty fields, most of them null
    host: null,
    id: null,
    name: null,
    variable: null,
    workflows: [],
    metadata: {}
} as unknown as DotCMSContentType;   // ← this

That trailing cast means none of those fields is checked against DotCMSContentType. The model declares baseType, clazz, id, name, variable and others as required non-null, and the fixture sets them to null. Nothing reports it, in a fixture that is spread into content-type specs across the whole workspace.

How it surfaced

While finishing #35933, seven fixtures across two dotcms-ui specs set host: null on a DotCMSContentType. That turned out to be correct — the API really does return host: null for a content type not scoped to a site — so DotCMSContentType.host was widened to string | null in #36957, with getProp(item) { return item || ''; } in the content-types form already written for exactly that value.

The point is how it was found: only because two specs overrode the field after the spread, which put the assignment outside the cast. Every field that specs simply inherit is still unchecked. There is no way to tell, today, which of the remaining nulls are like host (real, and the model is wrong) and which are fixture sloppiness (the model is right).

Proposed approach

1. Change the cast to a real annotation and see what breaks:

   export const dotcmsContentTypeBasicMock: DotCMSContentType = { … };
   

2. Triage each error into one of two buckets, and say which in the PR:
   • The model is wrong — the backend really sends null/absent. Widen the model, as host was.
   • The fixture is wrong — give it a valid zero value ('', [], a real clazz).
3. Do not resolve a case by re-adding a narrower cast. If a field genuinely cannot be typed, @ts-expect-error with a linked issue is preferable — at least it is visible.
4. Measure the blast radius before and after: utils-testing has many consumers and several are strict.

Acceptance Criteria

• dotcmsContentTypeBasicMock is annotated, not cast
• Every field either satisfies DotCMSContentType or the model was widened with a note on why
• libs/utils-testing tsconfig.lib.json and tsconfig.spec.json at 0
• Every strict consumer of utils-testing still at 0 — list them in the PR with before/after
• nx run-many -t test no worse than baseline
• Same treatment considered for the other blanket casts in that file, if any

Notes

• utils-testing:lint currently fails with 36 errors on main, unrelated to this and pre-existing — do not let it mask the verification.
• Related: #35932, #36957 (where DotCMSContentType.host was widened).

Start in libs/utils-testing/src/lib/dot-content-types.mock.ts and inspect DotCMSContentType plus the other blanket casts in that file. Replace the unchecked fixture typing, then run libs/utils-testing tsconfig.lib.json and tsconfig.spec.json to triage errors and inspect strict consumers across the workspace. Done means the listed type checks are clean, tests are no worse than baseline, and the PR records the consumer blast radius and model-versus-fixture decisions.