fix: make build cache relocatable when using Baseline by storing relative paths

[Copilot]

When using a shared build cache across different workspace directories, LintErrorResult serialized lintedFile as an absolute path. On cache restoration in a relocated project, baseline filtering broke because toRelativeString(newProjectDir) on a stale absolute path produced a path like ../../original/src/... instead of src/..., causing all baseline-suppressed errors to surface as real failures.

Changes

• LintErrorResult — bumped serialVersionUID to invalidate stale cached binaries containing absolute paths
• KtLintWorkAction — added projectDirectory parameter; converts each linted file to a project-relative path before writing to the .bin output:

  LintErrorResult(File(it.toRelativeString(projectDir)), result.lintErrors)

• BaseKtLintCheckTask — stores projectDir eagerly; passes it to the work action; resolves stored relative paths back to absolute when loading prior errors for incremental runs
• ConsoleReportWorkAction / GenerateReportsWorkAction — resolve lintedFile against projectDir for absolute-path operations (logging, reporter output); use lintedFile.path directly for baseline map lookup (already relative)
• GenerateBaselineWorkAction — uses lintedFile.path directly instead of toRelativeString(projectDir) since the path is now already relative
• BuildCacheTest — adds checkWithBaselineIsRelocatable: generates a baseline, primes the cache in the original directory, then verifies both runKtlintCheckOverMainSourceSet and ktlintMainSourceSetCheck are FROM_CACHE in the relocated project

[JLLeitschuh]

@copilot please fix the requirement for a change log file entry.

Please remember that this needs to be added every time copilot creates a pull request

[Copilot]

@copilot please fix the requirement for a change log file entry.

Please remember that this needs to be added every time copilot creates a pull request

Added a CHANGELOG.md entry under [Unreleased] in commit chore: add CHANGELOG.md entry for PR #1074.

[JLLeitschuh]

This looks reasonable to me. @wakingrufus what do you think?

[wakingrufus]

i think this should be a proper @InputDirectory property, and we should probably remove projectLayout from the constructor parameters and move the logic for setting properties derived from the layout to the plugin code which creates these tasks. this will make it work better with configuration cache

[JLLeitschuh]

If we make the entire projectDir an @InputDirectory won't that mean that the whole directory is tracked as an input? Thus any changes to any subfile, not just kotlin files would invalidate the task?

@copilot thoughts?

[Copilot]

Yes, that concern is valid. Annotating projectDirectory with @InputDirectory would cause Gradle to fingerprint every file under the project root, so any change to any file — including non-Kotlin files — would invalidate the task. That's exactly the kind of over-tracking we want to avoid.

The projectDirectory is only used as an anchor for computing relative paths (not as a content input), so the right annotation is @Internal. The actual content-based inputs are already tracked precisely via @get:InputFiles source with PathSensitivity.RELATIVE.

@wakingrufus's broader point about moving layout-derived property initialization out of the constructor and into the plugin's task-registration code is still a good one for configuration-cache hygiene, but that's orthogonal to the annotation question — and for the path-anchor use-case, @Internal is the correct choice regardless of where the value is set.