Fix(#1555): stale plugin descriptor for rebuilt reactor plugins

[HarshMehta112]

Problem

When a project builds a Maven plugin in its own reactor (e.g. mvnd verify),
subsequent daemon invocations keep serving a stale plugin descriptor even
after the plugin's code changes. The reported symptom is the threadSafe flag
not being re-read: toggle a Mojo's @Mojo(threadSafe = ...), rebuild, and the
daemon still uses the old value (#877).

Root cause

InvalidatingRealmCacheEventSpy already evicts reactor plugin realms and
extension realms at the end of each build (any realm whose URLs point under
multiModuleProjectDirectory). However, the PluginDescriptor — which carries
the threadSafe flag, @Parameter default values, etc. — is stored in a
separate singleton cache (InvalidatingPluginDescriptorCache) that was never
evicted there.

The timestamp-based invalidation cannot cover this case: with verify/test
(no install), a reactor plugin is resolved to a target/classes directory.
A directory's lastModifiedTime does not change when a .class file inside it
is rewritten, so the cached descriptor's file state looks unchanged and the stale
descriptor is reused. (The existing ModuleAndPluginNativeIT does not hit this
because it uses clean install, which rewrites the jar in the local repo and
bumps its mtime, invalidating everything.)

Fix

Extend InvalidatingRealmCacheEventSpy to also evict the
InvalidatingPluginDescriptorCache and InvalidatingPluginArtifactsCache
entries that refer to artifacts in the build tree (or match the configured
mvnd.pluginRealmEvictPattern) at MavenExecutionResult. Eviction is driven by
CacheRecord.getDependencyPaths(), consistent with the existing realm eviction.

Test

Adds ReactorPluginDescriptorReloadTest, which runs clean package (no install,
so the plugin stays a target/classes directory), changes a @Parameter
defaultValue between two daemon invocations, and asserts the new value takes
effect. This fails before the fix and passes after.

Note: integration-tests test sources currently do not compile on master
(JvmTestClient/MvndTestExtension were not updated after the #970 client API
refactor), so this IT could not be run locally. The daemon change itself
compiles and passes spotless.

Fixes #1555