Pipe structured BuilderProblems directly into DiagnosticCollector instead of re-logging as text

## Context

PR #12572 (Build Report Foundation) introduced a warning collection pipeline that intercepts SLF4J WARN-level log calls via `BuildReportCollector.captureLogEvent()` and auto-creates `BuilderProblem` objects with synthetic keys (`auto:xxx`).

However, Maven already creates **structured** `BuilderProblem` objects during model/settings/toolchains validation (with `key`, `suggestion`, `documentationUrl`, `source:line:column`) and plugin validation (deprecated mojos, Maven 2 dependencies, etc.). These are currently re-logged as plain text, losing all structured metadata.

## Problem

When the SLF4J hook intercepts the re-logged text, it creates a new synthetic `BuilderProblem` with:
- An auto-generated key (`auto:logger-name:hash`) instead of the original meaningful key
- No `suggestion`
- No `documentationUrl`
- No source location

The original structured `BuilderProblem` data is discarded.

## Implementation Status

### ✅ Done — Plugin validation (PR #12647)

PR #12647 implements structured `BuilderProblem` piping for all plugin validation pathways:

| Pathway | Component | Status |
|---------|-----------|--------|
| 1 — Model validation | `DefaultModelProblemCollector` | ✅ Verified existing |
| 2 — Plugin parameter validation | `AbstractMavenPluginParametersValidator` (3 validators) | ✅ Implemented |
| 3 — Plugin dependency validation | `AbstractMavenPluginDependenciesValidator` (4 validators) | ✅ Implemented |
| 4 — Contextualizable check | `DefaultMavenPluginManager` | ✅ Implemented |
| 5 — PluginValidationManager API | Migrated from `String` → `BuilderProblem` | ✅ Implemented |

Additionally, `PluginValidationManager` was migrated to accept `BuilderProblem` natively, with deprecated String-based default methods for backward compatibility.

### 🔲 Remaining — Settings and toolchains validation

In `LookupInvoker` and `MavenInvoker`, settings/toolchains `BuilderProblem` objects are still re-logged as text before being captured. Same pattern as above — pipe the original `BuilderProblem` directly instead of only logging the message text.

### Validators affected

| Validator | Status |
|-----------|--------|
| `DefaultModelValidator` (~35 sites) | ✅ Already structured (Pathway 1) |
| `DeprecatedPluginValidator` | ✅ PR #12647 |
| `Maven2DependenciesValidator` | ✅ PR #12647 |
| `Maven3CompatDependenciesValidator` | ✅ PR #12647 |
| `MavenScopeDependenciesValidator` | ✅ PR #12647 |
| `MavenMixedDependenciesValidator` | ✅ PR #12647 |
| `ReadOnlyPluginParametersValidator` | ✅ PR #12647 |
| `DeprecatedCoreExpressionValidator` | ✅ PR #12647 |
| `DefaultSettingsValidator` (~15 sites) | 🔲 Remaining |
| `DefaultToolchainsBuilder` | 🔲 Remaining |
| Profile activators (File, JDK) | 🔲 Remaining |

## Expected Outcome

`mvnlog --diagnostics` displays full structured information:
```
Problems: 2 warnings

[WARN] 'prerequisites' is deprecated pom.xml
key: deprecated-prerequisites
suggestion: Use the maven-enforcer-plugin instead
docs: https://maven.apache.org/pom.html#prerequisites

[WARN] Plugin uses deprecated Maven 2 API maven-shade-plugin:3.5.0
key: plugin-maven2-dependency
suggestion: Update to a version that uses Maven 4 API
```

## Depends on

- #12572 (Build Report Foundation)

Start by tracing the remaining validation paths in LookupInvoker and MavenInvoker, then inspect DefaultSettingsValidator, DefaultToolchainsBuilder, and the File and JDK profile activators. Compare their handling with the structured piping completed for plugin validation. Done means settings and toolchains BuilderProblem metadata reaches DiagnosticCollector intact and appears in mvnlog --diagnostics.

Written by the indexing model from the issue text.