Enlighten ResolveKeySource for multithreaded mode

[jankratochvilcz]

Adds [MSBuildMultiThreadableTask] and IMultiThreadableTask to ResolveKeySource. Absolutizes KeyFile before File.OpenRead() and CertificateFile before FileExists/GetCertContentType/Import/X509Certificate2 ctor, while preserving the original paths for [Output] ResolvedKeyFile property and error messages.

Fixes #13620
Parent epic: #11834

[ViktorHofer]

/review

[github-actions]

✅ Expert Code Review (command) completed successfully!

[github-actions]

Expert Code Review — 24-Dimension Analysis

Verdict: Clean PR with one moderate observation

Summary

This PR correctly applies the established IMultiThreadableTask pattern to ResolveKeySource, matching the approach used for Copy, Delete, Move, Touch, and ~15 other enlightened tasks. The changes are minimal, focused, and mechanically correct.

Dimension Results (24 dimensions evaluated)

Dimension	Result	Notes
1. Backwards Compatibility	✅ LGTM	TaskEnvironment.Fallback preserves single-process behavior identically
2. ChangeWave Discipline	✅ LGTM	Multithreaded mode is opt-in; no ChangeWave needed
3. Performance	✅ LGTM	One GetAbsolutePath call per execution — negligible
4. Test Coverage	⚠️ MODERATE	See inline comment — no tests exist for this task
5. Error Message Quality	✅ LGTM	No new messages; originals correctly preserved
6. Logging	✅ LGTM	No behavioral change requiring new diagnostics
7. String Comparison	✅ LGTM	No comparison logic changed
8. API Surface	✅ LGTM	TaskEnvironment property is public per IMultiThreadableTask contract
9. Target Authoring	N/A	Not a .targets file
10. Design	✅ LGTM	Follows established pattern precisely
11. Cross-Platform	✅ LGTM	AbsolutePath/Path.Combine handles cross-platform correctly
12. Code Simplification	✅ LGTM	Clean, minimal changes
13. Concurrency	✅ LGTM	No shared mutable state; HashFromBlob is pure; StrongNameHelpers uses [ThreadStatic]
14. Naming	✅ LGTM	keyFilePath and certificateFilePath are clear
15. SDK Integration	N/A
16. Idiomatic C#	✅ LGTM	Follows codebase conventions
17. File I/O & Path Handling	✅ LGTM	Correctly uses GetAbsolutePath for all file I/O; preserves original paths for outputs/errors
18. Documentation	✅ LGTM
19. Build Infrastructure	N/A
20. Scope & PR Discipline	✅ LGTM	Single-file, focused change
21. Evaluation Model	N/A
22. Correctness & Edge Cases	✅ LGTM	Validated: absolute paths handled correctly by Path.Combine; null/empty guarded before GetAbsolutePath; #if FEATURE_PFX_SIGNING scoping correct
23. Dependency Management	N/A
24. Security	✅ LGTM	No security regression

Key Validations Performed

• Path.Combine behavior: Confirmed Path.Combine(base, absolutePath) correctly returns just the absolute path — no malformed paths
• Output preservation: ResolvedKeyFile (line 114) uses original KeyFile; error messages (lines 149, 150, 159, 246, 250) use original paths — correct
• #if guard placement: Both keyFilePath (line 124) and certificateFilePath (line 212) are inside #if FEATURE_PFX_SIGNING — correct
• Thread safety: No static mutable fields, HashFromBlob is pure, each instance operates independently

Generated by Expert Code Review (command) for issue #13623 · ● 6.7M

[github-actions]

Test Coverage — MODERATE

ResolveKeySource has zero unit tests in the repo, and this PR adds none. Other tasks enlightened for multithreaded mode (Copy, Delete, Move, Touch) all have test suites that set TaskEnvironment = TaskEnvironmentHelper.CreateForTest(). While this change is a mechanical pattern application and the infrastructure is tested centrally, consider adding at least a basic test that verifies:

1. KeyFile with a relative path resolves correctly via TaskEnvironment.GetAbsolutePath (e.g., using TaskEnvironment.CreateWithProjectDirectoryAndEnvironment)
2. ResolvedKeyFile and error messages preserve the original (non-absolutized) path

The pre-existing test gap isn't this PR's fault, but enlightenment is a good opportunity to start covering this task.

[teo-tsirpanis]

Is the attribute necessary if the class implements IMultiThreadableTask?