Make WrapDynaClassTest tolerate gc eviction of weak cache entries (1.X)

[rootvector2]

Follow-up to #419, where WrapDynaClassTest.testConcurrentCreateDynaClassReturnsSameInstance failed on 1.X CI (run).

The failure is the test asserting more than the cache guarantees, not the synchronization from #419. The per-classloader cache is weak-keyed (WeakFastHashMap delegates to WeakHashMap) and the CacheKey is referenced by nothing but the map, so any GC evicts the entry and the next createDynaClass call legitimately builds a new instance. No concurrency is needed to see it: on unmodified 1.X, createDynaClass, System.gc(), createDynaClass returns a distinct second instance. When a GC lands inside one of the test's rounds, a late thread misses the cache and the round observes two instances — exactly the CI failure (expected: <1> but was: <2>). Master is unaffected because the beanutils2 cache (ConcurrentReferenceHashMap) holds soft references, which survive ordinary GCs.

The fix allocates a WeakReference canary at the start of each round and only asserts the single-instance property when the canary shows no GC ran during the round; rounds a GC invalidated are skipped. testCreateDynaClassIsCached gets the same guard since it has the same sensitivity in a smaller window.

Verified locally:

• the guarded test still fails on the pre-Make WrapDynaClass instance cache thread-safe (1.X) #419 unsynchronized code, so the regression coverage is intact
• a temporary System.gc() hammer thread makes the unguarded test fail immediately with the CI error; the guarded test passes under the same hammer
• repeated normal runs pass

Same caveat as #419 and #416: the full default goal hits the one pre-existing failure in LocaleBeanificationTest.testContextClassloaderIndependence on my machine, which fails identically on unmodified 1.X; everything else passes.

• Read the contribution guidelines for this project.
• Read the ASF Generative Tooling Guidance if you use Artificial Intelligence (AI).
• I used AI to create any part of, or all of, this pull request. Which AI tool was used to create this pull request, and to what extent did it contribute?
• Run a successful build using the default Maven goal with mvn; that's mvn on the command line by itself.
• Write unit tests that match behavioral changes, where the tests fail if the changes to the runtime are not applied. This may not always be possible, but it is a best practice.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Each commit in the pull request should have a meaningful subject line and body. Note that a maintainer may squash commits during the merge process.