[41/44] Enable TS strict mode in edit-content

Description

Part of the strict-mode rollout epic #35932. Enable TypeScript strict mode for the edit-content project.

• Dependency layer: 8 (0 = leaf library, 10 = top-level app)
• Internal dependents: 3 project(s)
• Rollout order: 41 / 44

The original acceptance criteria were stale. They described a typescript-strict-plugin /
npx tsc-strict / @ts-strict-ignore approach that was dropped early in the epic. The approach
actually in force is documented in core-web/CLAUDE.md → TypeScript Strict Mode:
the six flags go in the project's own tsconfig.json, and tsconfig.base.json stays
"strict": false. The criteria below have been rewritten to match.

Acceptance Criteria

• The six flags are in libs/edit-content/tsconfig.json — not in tsconfig.spec.json, not in the base:
  forceConsistentCasingInFileNames, strict, noImplicitOverride,
  noPropertyAccessFromIndexSignature, noImplicitReturns, noFallthroughCasesInSwitch.
• tsconfig.spec.json does not override them. This project had explicit
  "strict": false and "noPropertyAccessFromIndexSignature": false opt-outs, which hid
  666 of the 944 errors the specs really had.
• pnpm exec tsc -p libs/edit-content/tsconfig.lib.json --noEmit → 0 (was 101 own).
• pnpm exec tsc -p libs/edit-content/tsconfig.spec.json --noEmit → 0 (was 208 own).
• No new any. Every remaining cast is as unknown as T at a fixture that is deliberately
  out of contract, each with a comment saying why.
• No production non-null assertions added — @typescript-eslint/no-non-null-assertion is a
  warning in production code and off only for *.spec.ts.
• nx run edit-content:lint — 0 errors, 11 warnings, identical to the pre-existing baseline.
• nx run edit-content:test — 112 suites / 2218 passing, unchanged.
• nx affected -t build — all 7 affected projects build.
• Blast radius: 0 errors across all 12 strict projects after every shared-model change.

Measurement caveats that apply to this project

These cost real time on this epic; all six are now in core-web/CLAUDE.md.

1. nx run <project>:test never type-checks. ts-jest copies TypeScript's isolatedModules
   into its own transpile-only switch, so passing tests are never evidence that specs compile.
2. TS2688 (a types entry that is not installed) aborts before semantic checking.
3. TS6053 (a files entry pointing at a missing file) aborts likewise.
4. TS5101 / TS5107 (deprecated baseUrl, moduleResolution: node10) abort likewise.
5. tsc -p does not check templates — only a build does.
6. moduleResolution: node10 cannot resolve @dotcms/* subpath exports.

General rule: any TS5xxx, TS6xxx or TS2688 error is a configuration error. tsc never
reached the code, so the count after it means nothing. Read the first error before trusting the
last number.

Two more specific to this project

• libs/edit-content has no build target — only test. Its templates have therefore never
  been type-checked, so the strictTemplates in its angularCompilerOptions is declared but inert.
  Same gap as libs/block-editor. Raised on the epic.
• tsconfig.lib.json did not exclude test fixtures. mocks.ts files that import
  @dotcms/utils-testing were compiled as production with types: [], producing 27
  Cannot find name 'jest' errors that had nothing to do with this library's sources. Identical
  defect to template-builder (#35958). Note that exclude only drops them as root files — it
  does not stop tsc pulling a file in when something imports it, which is exactly what makes the
  change safe: no production file imports any of those fixtures.

Priority

Medium

Additional Context

One project in the bottom-up rollout tracked by epic #35932.

Read core-web/CLAUDE.md's TypeScript Strict Mode guidance, then inspect libs/edit-content/tsconfig.json, tsconfig.spec.json, and tsconfig.lib.json. Run the two tsc commands first; the work is complete when both report zero errors, lint and tests match their stated baselines, and the affected projects build without blast-radius errors.