Clear cached JS for stale types even when currently unreachable

[kevinushey]

Problem

In incremental (Super Dev Mode) compiles, MinimalRebuildCache.computeAndClearStaleTypesCache() filters the stale type set down to currently-reachable types before clearing cached JS. The filter's comment assumes that an unreachable stale type has no cached JS ("since they're missing JS, they will already be fully traversed when seen in Unify") -- but that invariant does not hold: a type that merely loses reachability (without its compilation unit being modified) keeps its cached JS.

When such a type becomes reachable again in a later compile, UnifyAst.needsNewJs() sees JS present, marks the type reference-only, and splices the stale chunk into the output. If the type's shape changed in the interim -- for example synthetic lambda types being renumbered because a lambda was added earlier in the file -- freshly generated call sites reference a newly allocated global name while the stale chunk defines the old one:

ReferenceError: Widgets$lambda$2$Type_2_g$ is not defined

Even when the names happen to line up, the output silently runs outdated code. Because the code server persists the MinimalRebuildCache to disk ($TMPDIR/gwt-cache-*), the corruption survives code-server restarts and "clean" rebuilds of the application, which makes it look thoroughly mysterious to users. This is the likely root cause of the long-standing symptom reports in #9565 (see analysis), where several commenters found that deleting the code server's tmp files resolved the error.

Reproduction

Three-step incremental compile sequence (encoded in the included test):

1. Compile with TestEntryPoint.onModuleLoad() calling both Widgets.ping() and Widgets.trigger(); trigger() contains several lambdas. Their JS is cached.
2. Modify only the entry point to stop calling trigger(). Widgets is not modified, so its lambda types keep their cached JS -- but they are now unreachable.
3. Modify the entry point to call trigger() again, and modify Widgets so an extra lambda is inserted first (renumbering the synthetic lambda types). The lambda types are stale, but the reachability filter (based on the previous compile's reachability) skips clearing them; the output mixes stale definitions with fresh call sites and contains a new Widgets$lambda$2$Type_2_g$(...) whose constructor is never defined.

Fix

Clear cached output for the full stale set before applying the reachability filter. The filter still limits which types are artificially retraversed (its stated purpose); clearing the JS of a currently-unreachable stale type costs nothing (it is not emitted) and restores the invariant that a cached JS entry is always current -- when the type becomes reachable again, needsNewJs() correctly triggers a fresh traversal.

Testing

• New CompilerTest#testIncrementalRecompile_unreachableStaleTypeRegainsReachability fails on current main with lambda type constructor Widgets$lambda$2$Type_2_g$ is referenced but never defined and passes with the fix.
• Verified end-to-end against a live CodeServer (GWT 2.12.2): the same three-step sequence produces the dangling reference without the fix and consistent output with it.
• MinimalRebuildCacheTest passes unchanged.

Fixes #9565.