Fix TS2454 false positive for closed-over mutable variables - #63984

Fixes #63981

Problem

Under --strict, a top-level let that is assigned at the top level gets reported as used before assignment when a closure compound-assigns it:

export {};

let count: number;

function makeCallback(p: string) {
  return () => {
    count += 1; // error TS2454: Variable 'count' is used before being assigned.
    return p;
  };
}

count = 0;
makeCallback('x')();

count is assigned before the callback can ever run, and the reference inside the arrow is an outer-variable reference, so definite assignment analysis should not fire here. 5.7 and 6.0 both accept this. The error is new in 7.

Cause

ensureAssignmentsMarked returned early whenever the symbol already had a non-zero lastAssignmentPos. That is not a safe "already computed" signal, because lastAssignmentPos can be written by a walk of a nested function that never visits the declaring container.

What happens in the repro:

1. Checking "return p" inside the arrow calls isPastLastAssignment(p). p is declared in makeCallback, so markNodeAssignments walks only that function's subtree.
2. That walk sees "count += 1". The referencing function (the arrow) is not the declaring function (the source file), so it records count.lastAssignmentPos = MaxInt32. It never reaches the top-level "count = 0", so hasDefiniteAssignment stays false.
3. Checking "count += 1" then calls isSymbolAssignedDefinitely(count), which hits the early return. The source file is never walked, so "count = 0" is never seen.
4. With hasDefiniteAssignment false, isNeverInitialized becomes true, which clears assumeInitialized even though isOuterVariable is true, and the error is reported.

Strada has no equivalent early return. Its only guard is the AssignmentsMarked node-links flag on the declaring container, which is per-container and therefore correct.

Solution

Drop the early return. The AssignmentsMarked flag together with hasParentWithAssignmentsMarked already guarantees each container is walked at most once, so the removed check only saved one FindAncestor and a map lookup, and it did that by skipping the walk that produces the right answer. This puts the behavior back in line with Strada.

Tests

Added tsc/testdata/tests/cases/compiler/definiteAssignmentOfClosedOverVariable.ts with three cases:

• the repro from the issue, which must now be clean
• the same bug without "return p", using a separate nested closure that references the parameter, which shows the trigger is the early nested walk and not the returned expression
• a variable that really is never definitely assigned, which must still report TS2454

The baseline has exactly one diagnostic, on the third case. Running the same file through tsc@5.7.3 gives the identical single error on the identical line, so the port now matches Strada in both directions.

Across the full suite the only baselines written were the three for this new test, so nothing else moved. That is worth noting because ensureAssignmentsMarked also feeds isSymbolAssigned and isPastLastAssignment, which affect narrowing of closed-over variables and not just TS2454.

Checklist

• There is an associated issue in the Backlog milestone (required)
  TS2454 false positive when a callback mutates an outer let and returns the enclosing function's parameter #63981 has not been triaged yet, so it has no milestone. I cannot set one. Happy to wait for triage if you would rather look at the issue first.
• Code is up-to-date with the main branch
• You've successfully run npx hereby test
• You've successfully run npx hereby lint
• You've successfully run npx hereby check:format
• There are new or updated tests validating the change