Put main's preview lane one patch above the current release

[ChrisonSimtian]

Puts main's preview lane one patch above the current release instead of one minor above.

What changed

• version.json: 10.5.0-preview.{height} → 10.4.1-preview.{height}. Latest GA is 10.4.0, so one patch above is 10.4.1.
• release.versionIncrement: minor → build. In Nerdbank.GitVersioning, build increments the third component. Left on minor, the next nbgv prepare-release would move main back to a minor bump and undo this.

Why

The rule is that main always sits one patch level above the current release. 10.5.0 claimed a minor that has not been planned or cut.

Verification

nbgv get-version on this branch:

Version:                      10.4.1
AssemblyInformationalVersion: 10.4.1-preview.1+317c5f4d83
NuGetPackageVersion:          10.4.1-preview.1.g317c5f4d83

version.json parses, and no test asserts the repo's version scheme. The 2026.1.0 strings in PublishPackageRouterSpecs and BuildGraphUtilitySpecs are fixtures for glob matching and version-string trimming, not assertions about this file.

Follow-up needed before this helps consumers

Three preview versions above 10.4.1 are already on the GitHub Packages feed, published from main before this change:

• 10.5.0-preview.2.gace05f3695
• 10.5.0-preview.8.g2b0d7ceb46
• 10.5.0-preview.9.gc22ef81243

10.5.0-preview.9 sorts above 10.4.1-preview.N for every future N, so anyone resolving the newest prerelease keeps getting the 10 August build and never sees a new preview. Those three versions need deleting from GitHub Packages, on all 24 packages, for this change to take effect. Preview versions are disposable per ADR-0004, so deleting them is in line with the channel's contract.

Notes

• release.branchName is release/{version}, which would create release/10.4, but the existing branch is release/v10.4 and publicReleaseRefSpec matches the v-prefixed form. Pre-existing mismatch, not touched here.
• AGENTS.md and ADR-0004 still describe calendar versioning (YYYY.MINOR.PATCH). The repo has been on the 10.x line since 10.4.0, so those documents are already out of step. This PR follows the shipped reality and does not try to settle that.