Cache projectsWithDeployExecution to fix O(N²) reactor scan (#684)

* Cache projectsWithDeployExecution list to avoid O(N²) reactor scan

DeployMojo.allProjectsMarked() calls hasDeployExecution() for every
reactor project on every module invocation. hasDeployExecution() calls
getPluginsAsMap() for each project, producing O(N²) evaluations in a
large reactor build (e.g., 4383² ≈ 19.2M calls in a 4383-module project).

Fix: cache the filtered list of projects with deploy executions in the
first reactor project's plugin context. The list is invariant during a
build. Also simplify allProjectsMarked() to only check the projects
that actually have deploy executions, rather than iterating the full
reactor and testing the disjunction (hasState || !hasDeployExecution).

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

* fix: synchronize cache population for parallel builds

The get/check/put on the plugin context map is a TOCTOU race — in
parallel builds (-T), multiple threads can see the cache as null
and each recompute the full reactor scan, defeating the cache.

Wrap the compound operation in synchronized(ctx) so only the first
thread computes and all others reuse the result. Session.getPluginContext()
returns Map (not ConcurrentMap), so synchronized is the safest choice
that does not depend on the underlying implementation.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

* refactor: use computeIfAbsent instead of synchronized block

Replace the synchronized get/check/put with a single computeIfAbsent
call. The plugin context map is a ConcurrentHashMap at runtime, so
computeIfAbsent is atomic and guarantees single-invocation. Even if
the underlying Map implementation changed, the worst case is redundant
computation of the same invariant list — a perf regression, not a bug.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>