Checker accepts incompatible copies of public getters that read later fields #3518

The checker accepts an incompatible assignment when a class field copies the return of an inferred public getter, and that getter reads a later field without a type annotation.

class C {
    value = this.x;
    stored = 1;
    get x() { return this.stored; }
}
const wrong: string = new C().value;

Expected: TypeScript 6.0.3 reports TS2322 because C.value is number.

Actual: SharpTS exits 0 with no diagnostics. Moving stored = 1 before value = this.x, or annotating it as stored: number = 1 in its original position, makes the same SharpTS build reject the incompatible assignment. These are check-only observations. They do not require running an initializer before the later field exists.

node external/typescript/lib/tsc.js --ignoreConfig --target ES2022 --strict --skipLibCheck --noEmit case.ts
dotnet SharpTS.dll --no-tsconfig --noLib --strict --noEmit case.ts

Reproduced on the frozen pre-PR #3510 main build at cabb41636, SharpTS.dll SHA-256 5335B14C2A96172D0372D8FCDD75264741EB8A0B19C0273737C3BBF2967D3ACE. Found while validating the independent private-accessor dependency correction in #3483.

Source lead: TypeChecker.ClassFieldInference.cs retains an unresolved getter result if it reads a pending field during ordinary initialization. This leaves the dependent field without the completed type used when the backing field is already typed. Related closed #2450 (fixed by #2920) concerned rejecting callable getter results and documented some forward-dependency controls. This reduction shows a remaining false acceptance through an ordinary copied field with no callable result, index access or static receiver. All-state searches for inferred getter/field inference, getter/later field, and getter/forward member found no open owner.