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

[JanProvaznik]

@jankratochvilcz mergeable?
this is showing up on vmr build as +20s attributable to it :)

[jankratochvilcz]

@JanProvaznik addressed both inline questions — short version: both GetAbsolutePath calls are behind the existing !string.IsNullOrEmpty(...) guards, and the KeyFile one is inside the same try that already wrapped File.OpenRead, so exception handling is unchanged (it actually throws strictly less than File.OpenRead since the Path.Combine used doesn't throw on invalid characters).

Also rebased onto current main (the branch was 145 commits behind) and re-verified the build. No code changes beyond the rebase. Ready for re-review.