Build report: structured JSON report with per-mojo log capture

[gnodet]

Summary

Part 2 of the logging feature chain (depends on #12694 — logging foundation).

Adds a structured build report that captures per-module and per-mojo execution results, timing, log events, and failures as a JSON file at the end of every build.

15 files changed, ~2700 insertions — focused on report data model, collection, and serialization.

What's in this PR

Layer	Files	Description
API	BuildReport, BuildStatus, ModuleReport, MojoReport, FailureReport	Immutable interfaces for the report data model
Impl	DefaultBuildReport, DefaultModuleReport, DefaultMojoReport, DefaultFailureReport	Record implementations
Collector	BuildReportCollector	EventSpy that tracks lifecycle events and captures log output via LogEventSink, routing to mojo/module/build-level buffers
Writer	BuildReportJsonWriter	Zero-dependency JSON serializer with stable field order
Tests	3 test classes, 17 tests	Unit tests for collector, JSON writer, and integration

Key design decisions

• EventSpy pattern: BuildReportCollector is a @Named @Singleton that extends AbstractEventSpy, discovered automatically — no wiring changes needed
• Thread-based log routing: Uses ConcurrentHashMap<Long, String> (thread ID → mojo/project key) to associate log events with the correct scope in parallel builds
• Dual sink architecture: Uses LogEventSink (4-arg) independently from the existing LogSink (5-arg) used by ProjectBuildLogAppender — no interference with console output
• Atomic writes: Reports are written to a temp file, then atomic-moved into place with a timestamped filename and a build-report-latest.json symlink
• Defensive: onSessionEnded wraps report generation in try-catch so report failures never crash the build

What's NOT in this PR (deferred to later PRs)

• BuilderProblem enrichments (key, suggestion, documentationUrl) — Warning mode, diagnostic collector, BuilderProblem enrichments #12698
• Diagnostic collection and warning deduplication — Warning mode, diagnostic collector, BuilderProblem enrichments #12698
• --warning-mode CLI flag — Warning mode, diagnostic collector, BuilderProblem enrichments #12698
• Console modes (--console=plain/rich/machine) — Console modes: --console=plain/rich/verbose/machine #12697
• mvnlog viewer tool — mvnlog: build log viewer, integration tests, script routing #12699

PR chain

#	PR	Feature
1	#12694	Logging foundation
2	This PR	Build report
3	#12697	Console modes
4	#12698	Warning mode + diagnostics
5	#12699	mvnlog viewer
6	#12702	Structured problems pipeline
7	#12714	TRACE level migration

Test plan

• 17 new unit/integration tests pass
• Full Maven test suite passes (same results as base branch)
• CI validation

🤖 Generated with Claude Code

[gnodet]

Well-designed build report feature with clean API/impl separation and comprehensive tests. A few issues noted below.

Also noted:

• The architecture is solid: clean API interfaces in maven-api-core, record-based implementations in maven-core, EventSpy pattern for automatic discovery, thread-based log routing for parallel-build safety, atomic file writes with symlink swap.
• The PR correctly depends on PR #12694 (logging foundation) — should not be merged until #12694 lands.
• No test for the captureLogEvent routing logic (mojo-level vs module-level vs build-level buffers). This is the core routing mechanism and warrants at least one test exercising the dispatch.

This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.

Claude Code on behalf of gnodet

[gnodet]

The Javadoc says "Beyond this, events are dropped and a truncation notice is appended" but captureLogEvent silently drops events without appending any truncation notice. Either append a synthetic LogEvent indicating truncation (e.g. with level WARN and message "... N events truncated"), or update the Javadoc to say events are silently dropped.

[gnodet]

The hasMore parameter is unused (annotated @SuppressWarnings("unused")) and all call sites pass true. If trailing comma control is no longer needed, the parameter should be removed to reduce confusion.

Suggested change

	private static void writeModule(StringBuilder sb, ModuleReport module, int indent) {
	private static void writeNullableField(StringBuilder sb, int indent, String key, String value) {