## What kind of change does this PR introduce?
Fixing broken documentation links (https://reactiveui.net/docs/ ->
https://reactiveui.net/documentation/)

## Checklist
- [x] I have read the [Contribute
guide](https://www.reactiveui.net/contribute/index.html)
- [x] Docs have been added or updated (for bug fixes / features)
- [x] Changes target the `main` branch
- [x] PR title follows [Conventional
Commits](https://www.conventionalcommits.org/)

## What kind of change does this PR introduce?

Build (dependency updates), plus the analyzer fallout they caused and
one docs removal.

## What is the new behavior?

- Central package versions are current. Every `PackageVersion` in
`src/Directory.Packages.props` and
`src/benchmarks/Directory.Packages.props` was checked against nuget.org:
  - Sharp analyzer suite 3.38.1 -> 3.40.1
  - Third-party C# analyzer package moved to its current release
  - TUnit 1.61.38 -> 1.63.0
  - Microsoft.Testing.Platform.MSBuild 2.3.2 -> 2.3.3
- The analyzer bump introduced SST1537, which flagged 15 sites where a
comment sat between an expression-bodied member's `=>` and its
expression. Those comments have moved:
- Substantive explanations now live in `<remarks>` on the member's XML
docs, where they are actually discoverable.
- Bare `Act & Assert` markers on single-expression tests are gone; they
restated the one line beneath them.
- `CLAUDE.md` no longer documents running the Windows test suites
through Wine.

## What is the current behavior?

- The pinned versions were behind on the four packages above.
- The 15 comment sites failed the build once the newer analyzers were in
place.
- `CLAUDE.md` told agents to run WPF and WinForms tests under Wine on
Linux. Wine does not enforce WPF `Dispatcher` thread affinity, so
results for the marshalling and background-thread tests were not
trustworthy in the one place a Windows host mattered most.

## What might this PR break?

- No product code changed. The diff is limited to package versions,
test-project comments, and `CLAUDE.md`.
- Framework-aligned pins were deliberately left alone. Entries like
`AspNetVersion` per TFM, `MicrosoftExtensionsVersion` and
`SystemTextJsonVersion` are each already the newest release inside their
own major.minor band, so bumping them to the newest overall version
would have broken TFM alignment.

## Checklist
- [x] I have read the [Contribute
guide](https://www.reactiveui.net/contribute/index.html)
- [x] Tests have been added or updated (for bug fixes / features)
- [x] Docs have been added or updated (for bug fixes / features)
- [x] Changes target the `main` branch
- [x] PR title follows [Conventional
Commits](https://www.conventionalcommits.org/)

## Additional information

Version discovery was done with a throwaway single-file `dotnet run`
tool built on `NuGet.Protocol`, querying
`FindPackageByIdResource.GetAllVersionsAsync` for every declared
package. It resolves `$(Property)` indirections back to their
`PropertyGroup` definitions and compares each conditional value inside
its own major.minor band, so TFM-aligned pins are not reported as stale
against an unrelated major.

Verified on Linux:

- `dotnet build reactiveui.slnx -c Release -t:Rebuild` - 0 warnings, 0
errors. This includes the Windows target frameworks, which compile here
via `EnableWindowsTargeting`.
- 2326 tests pass across ReactiveUI.Tests, ReactiveUI.Tests.Reactive,
Testing.Tests, Builder.Tests, Routing.Tests (+ .Reactive), Splat.Tests,
Blazor.Tests and AOT.Tests.

Not verified locally, left to CI on `windows-latest`: execution of the
WPF, WinForms and WinUI suites. `ReactiveUI.NonParallel.Mobile.Tests`
also needs iOS workloads that are not installed on this machine.

…#4427)

## What kind of change does this PR introduce?

Fix.

## What is the new behavior?

`ReactiveUI.Testing` and `ReactiveUI.Testing.Reactive` ship `net462`,
`net472` and `net481` again, alongside the modern `net8.0` - `net11.0`
targets. Verified by packing both projects and listing the package
contents:

```
ReactiveUI.Testing.nupkg           ReactiveUI.Testing.Reactive.nupkg
  lib/net462                         lib/net462
  lib/net472                         lib/net472
  lib/net481                         lib/net481
  lib/net8.0 net9.0 net10.0 net11.0  lib/net8.0 net9.0 net10.0 net11.0
```

The .NET Framework public surface is byte-identical to the `net8.0`
baseline, so nothing is reduced on the older frameworks.

## What is the current behavior?

Closes #4420

Since v23 both packages set
`<TargetFrameworks>$(ReactiveUIModernTargets)</TargetFrameworks>`, which
is `net8.0;net9.0;net10.0;net11.0`. The `ReactiveUI` package they exist
to test targets `$(ReactiveUIFinalTargetFrameworks)`, which does include
`$(ReactiveUIFrameworkTargets)` (`net462;net472;net481`). So a project
on .NET Framework could reference ReactiveUI but not its testing
helpers.

Note for anyone reading the issue: it points at
`ReactiveUITestingTargets` in `Directory.Build.props`. That property is
a red herring here - it is consumed only by test projects under
`src/tests`, never by the shipped packages. The actual driver was
`ReactiveUIModernTargets` in the two csproj files.

## What might this PR break?

- No source changed, and no public API changed on any existing target
framework. The four modern TFM baselines regenerate byte-identically.
- The two packages now build three additional target frameworks each, so
pack and CI time grow slightly.
- `ReactiveUI.Testing.Reactive` pulls `Microsoft.Reactive.Testing` on
the new frameworks; it resolves and compiles clean on all three.

## Checklist
- [x] I have read the [Contribute
guide](https://www.reactiveui.net/contribute/index.html)
- [x] Tests have been added or updated (for bug fixes / features)
- [x] Docs have been added or updated (for bug fixes / features)
- [x] Changes target the `main` branch
- [x] PR title follows [Conventional
Commits](https://www.conventionalcommits.org/)

## Additional information

The PublicAPI baselines for the six new (project, TFM) pairs were
produced with the repo's own `tools/generate-publicapi.sh`, which the
tooling README already names as the step for "after adding a new target
framework to a tracked library". Running it over both projects
regenerated all 14 pairs; the eight pre-existing ones came back
unchanged, which is the check that the generator is deterministic here
and that no existing surface moved.

Verified on Linux:

- `dotnet build reactiveui.slnx -c Release -t:Rebuild` - 0 warnings, 0
errors.
- Both testing projects rebuild clean across all seven target
frameworks.
- 4216 tests pass across ReactiveUI.Tests, ReactiveUI.Tests.Reactive,
ReactiveUI.Testing.Tests and ReactiveUI.Builder.Tests.

## What kind of change does this PR introduce?

Chore - Renovate configuration only. No product code, no build files, no
dependency versions change.

## What is the new behavior?

Adds repo-specific grouping on top of the shared `reactiveui/.github`
preset so related packages arrive as one reviewable PR:

- `analyzers`
- `build tooling`
- `test tooling`


- The shared preset holds all of `Microsoft.CodeAnalysis.*` on its
current major to pin the compiler API. `PublicApiAnalyzers` and
`BannedApiAnalyzers` ship on their own release line and are not part of
that toolchain, so their majors are allowed through again. The
compiler-API pin is unaffected.

## What is the current behavior?

These packages are ungrouped, so each one opens its own PR even when it
only makes sense to bump them together.

## What might this PR break?

Nothing at build time - this file only affects how Renovate batches its
own PRs. Any currently-open Renovate PR whose group name changes will be
closed and reopened under the new branch name.

## Checklist
- [x] I have read the [Contribute
guide](https://www.reactiveui.net/contribute/index.html)
- [ ] Tests have been added or updated (for bug fixes / features)
- [ ] Docs have been added or updated (for bug fixes / features)
- [x] Changes target the `main` branch
- [x] PR title follows [Conventional
Commits](https://www.conventionalcommits.org/)

## Additional information

Validated with `renovate-config-validator`. Every pattern was checked
against this repo's actual package list (no dead rules), and the merged
preset+repo rule set was resolved through Renovate's `applyPackageRules`
engine to confirm each package lands in the intended group.