Fix shortenFullyQualifiedTypes corrupting method references on fields (#3133)

[maxandersen]

Fixes #3133.

Problem

shortenFullyQualifiedTypes() corrupts a method reference on a field/variable. JavaParser parses the scope of localVar.field::method as a ClassOrInterfaceType (the LHS of :: is type-ambiguous), so the formatter treated catalog.aliases::get as a fully-qualified type, rewrote it to aliases::get, and injected a bogus import catalog.aliases; — which does not compile. It only manifests on spotlessApply (not the read-only spotlessCheck), so a developer formats, commits, and then the build breaks.

Before / After (the bug)

// input
return find(catalog.aliases::get);   // catalog = local var, aliases = Map field

// shortenFullyQualifiedTypes() produced:
import catalog.aliases;              // bogus
return find(aliases::get);          // qualifier dropped -> won't compile

Fix

The expression-context path (FieldAccessExpr / MethodCallExpr scopes) already guards against variable.field shapes via a known-package / minimum-depth heuristic. A method-reference scope, however, reaches the ClassOrInterfaceType visitor instead, which trusts any package-like (lowercase first segment) dotted name — so catalog.aliases slips through.

This routes method-reference scopes through the same heuristic: the existing inline check in processExpressionScope is extracted into one shared isTrustedFullyQualifiedName(dottedName, knownPackages) used by both paths. A dotted name is trusted as a fully-qualified type only when the package (segments before the first upper-case segment) is already known from imports / the file's own package / java.lang, or has at least two segments. This:

• leaves catalog.aliases::get alone (no upper-case type segment);
• also leaves single-segment, non-package scopes alone, e.g. a static-imported or field config.Database::connect (upper-case simple name but config is not a known package) — which the old type path mis-shortened;
• still shortens genuine FQN method references like java.lang.Integer::parseInt → Integer::parseInt.

No symbol resolution / classpath is used (consistent with the step's "when in doubt, leave it alone" design).

Tests

• issue3133_methodReferenceOnFieldNotShortened — catalog.aliases::get left untouched, no bogus import.
• methodReferenceWithSingleSegmentScopeLeftAlone — config.Database::connect left untouched.
• methodReferenceOnRealTypeStillShortened — java.lang.Integer::parseInt → Integer::parseInt.

All 39 ShortenFullyQualifiedTypesStepTest cases pass.

Found while enabling the step on a real codebase (jbangdev/jbang), where catalog.aliases::get broke the build.