feat/v2.1-polish-dsl-errors: sharpen v2 config-error UX + pin v2.1.0 release via .release-version

[vedanthvdev]

Why

Three small-but-sharp fixes uncovered by the v2.0.0-local pilot against security-service, bundled into one PR because they all close the same gap: "something in my build.gradle is wrong → the plugin told me exactly what to change".

Two fixes are DSL-error polish; the third teaches the release workflow a version-override mechanism so this PR's own merge can ship as v2.1.0 on a normal push-to-master without needing workflow_dispatch coordination. The mechanism is reusable for future minor/major bumps.

What

1. Targeted v2 migration hint on the three removed legacy knobs

Before (Gradle's generic error):

> Could not set unknown property 'runAllIfNoMatches' for extension
  'affectedTests' of type io.affectedtests.gradle.AffectedTestsExtension.

After (v2.1, via setRunAllIfNoMatches / setRunAllOnNonJavaChange / setExcludePaths shims on the extension):

> affectedTests.runAllIfNoMatches was removed in v2.0.0. Use
  onEmptyDiff = "full_suite" and/or onDiscoveryEmpty = "full_suite"
  instead (or set mode = "ci" / "strict" to get those defaults). See
  CHANGELOG.md v2.0 for the full migration table.

Kotlin DSL already gets a compile error naming the removed property so shims only fire for Groovy — which is where the unhelpful default lived.

2. gradlewTimeoutSeconds range check at configuration time

The v1.9.22 value >= 0 check lived on the core builder and only ran at task-execution. IDE sync, ./gradlew help, ./gradlew tasks all stayed green against a misconfigured build; operators only saw the rejection when they ran affectedTest.

v2.1 mirrors the check in AffectedTestsPlugin#apply via project.afterEvaluate, so the same message fires at configuration completion — IDE sync surfaces it immediately. Builder-side check stays as belt-and-braces for programmatic callers that bypass the DSL.

3. .release-version override file for merge-to-master minor/major releases

Until v2.1, the only way to ship a non-patch bump on a merge-to-master release was workflow_dispatch with an explicit version input. That meant every minor release had a coordination window where the auto-release on the merge push could mint an unwanted patch tag before the manual dispatch took over.

The workflow now reads a .release-version SemVer file at repo root (regex-validated before use) when no dispatch input is present, passes it to axion-release, and deletes the file in a [skip ci] follow-up commit after the tag → publish → GitHub-Release triad succeeds.

This PR commits .release-version = 2.1.0 so its own merge ships as v2.1.0 on the Gradle Plugin Portal. The file self-cleans afterwards so subsequent patch releases resume auto-incrementing.

Priority order in release.yml:

1. workflow_dispatch input (unchanged)
2. .release-version file (new)
3. Auto-patch-increment (unchanged)

Regression coverage

Pinned in AffectedTestsPluginTest:

• legacyKnobAssignmentThrowsWithV2MigrationHint_runAllIfNoMatches
• legacyKnobAssignmentThrowsWithV2MigrationHint_runAllOnNonJavaChange
• legacyKnobAssignmentThrowsWithV2MigrationHint_excludePaths
• negativeGradlewTimeoutFailsAtConfigurationTime

Each message assertion pins both the user-facing knob name AND the v2 replacement / valid-range bound, so a well-intentioned "tidy up the error message" refactor that drops either half is caught.

Revert-verified: reverting AffectedTestsPlugin.java in isolation (keeping the rest) makes negativeGradlewTimeoutFailsAtConfigurationTime fail at the assertion, not at compile. Reverting the extension shims makes the other three tests fail to compile — which is also a guard against silent regression.

The release-workflow logic was simulated locally against 9 input cases (input-wins, file-used, trailing-newline trimmed, empty file rejected, bad SemVer rejected, pre-release allowed, ...) before relying on it to ship v2.1.0.

Test plan

• ./gradlew check green on branch HEAD
• Revert-checks for both fixes
• YAML valid (ruby -e 'require "yaml"; YAML.load_file(...)')
• Release-workflow version-resolver simulated across 9 cases
• On merge: .release-version picked up → tag v2.1.0 → publish to Plugin Portal → GitHub Release → self-cleanup commit [skip ci]
• Post-merge: re-pilot the security-service scenarios against io.github.vedanthvdev.affectedtests:2.1.0 pulled directly from the portal (not mavenLocal)

Notes for reviewers

• The v2 breaking changes are already in master under the v1.9.23 tag that auto-patch-increment minted on the PR feat/v2.0-remove-legacy-knobs: Phase 3 — delete the v1 DSL surface for v2.0.0 #34 merge — so the Plugin Portal has v2-content under a patch version already. v2.1.0 is the first publicly tagged v2 release and supersedes v1.9.23 in name.
• README §Versioning has the new decision matrix entry for the file-based override.

[vedanthvdev]

Triggering CI - workflow didn't dispatch on initial push.