wrap-java: synchronize checked-in generated wrapper outputs - #13

Problem

The checked-in Java standard-library wrappers still emit unqualified Optional convenience calls, while the generator now emits self-qualified calls. Regeneration therefore changes ten tracked files, causing the JavaStdlib wrap-java up-to-date check to fail.

Regenerating runtime support also creates generated/JavaUtilUUID.swift alongside the hand-written JavaUtilUUID.swift. A subsequent Swift build fails because the same filename and projection are defined twice.

Changes

• Regenerate the standard-library wrappers, updating 18 Optional convenience calls to qualify their receivers with self.
• Replace the hand-written UUID projection with the generated projection at its normal tracked output path, so regeneration and subsequent builds remain consistent.
• Keep the Optional output refresh and the UUID projection replacement in separate commits. When contributing upstream, include them with their corresponding Optional receiver-qualification and Foundation UUID callback changes.

Validation

• All ten regenerated standard-library file hashes exactly match the post-regeneration hashes reported by the failing CI job.
• ./scripts/wrap-java-generate.sh completed; repeating regeneration produced no tracked output changes, including with the CI whitespace-tolerant diff check.
• swift test --disable-experimental-prebuilts --disable-sandbox: full Swift test suite passed after regeneration.
• ./gradlew :Samples:SwiftJavaExtractJNISampleApp:test --tests '*FoundationCallbackTest' --no-daemon: all five Foundation callback tests passed, including UUID round trips using the generated projection.
• swift-format lint --strict on the new generated projection and git diff --check passed.

Tested with Apple Swift 6.4 and JetBrains Runtime 25 on macOS.