[repo-assist] Fix paket pack failing when TargetFramework(s) are in conditional PropertyGroups

[github-actions]

🤖 This is an automated response from Repo Assist.

Closes #3799

Root cause

ProjectFile.getOutputDirectory looked up TargetFramework/TargetFrameworks using getTargetFramework/getTargetFrameworksParsed, which evaluate the project's conditional PropertyGroups against an empty property map (no Configuration/Platform). When a project puts its TargetFrameworks inside a PropertyGroup conditioned on Configuration (a common and MSBuild-valid pattern), the condition never matches, no framework is found, and paket pack/paket restore fails with:

Unable to find Release output path node in file ... for any known platforms

Fix

Added getTargetFrameworkWithDefaults / getTargetFrameworksParsedWithDefaults helpers that reuse the existing conditional-property evaluator (getPropertyWithDefaults) but seed it with the Configuration/Platform values getOutputDirectory already has. getOutputDirectory now uses these instead of the unconditioned variants, so conditional PropertyGroups keyed on Configuration/Platform are correctly evaluated.

This is a minimal, surgical change — the unconditioned getTargetFramework/getTargetFrameworksParsed functions are left untouched since they're used elsewhere (e.g. getTargetProfiles) where evaluating without Configuration/Platform context is intentional.

Test Status

• Added a new fixture MicrosoftNetSdkWithConditionalTargetFrameworks.csprojtest reproducing the issue's Condition="'$(Configuration)'=='Release'" pattern.
• Added a test verifying GetOutputDirectory no longer throws for Debug/Release configurations.
• dotnet build src/Paket.Core/Paket.Core.fsproj -c Release: succeeds (0 errors).
• dotnet test tests/Paket.Tests/Paket.Tests.fsproj -c Release --filter "FullyQualifiedName~OutputSpecs": net9.0 — 39/39 passed. The net461 target host failed to launch in this sandbox only because mono isn't installed here (Could not find 'mono' host), an environment limitation unrelated to the change — no code-caused failures.

---

As an AI assistant, I may make mistakes. Please review carefully before merging.

Generated by 🌈 Repo Assist, see workflow run. Learn more.
_{Comment /repo-assist to run again}

_{Add this agentic workflow to your repo}

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@ae8d551f07c7ed7619f8c58c7bb4c3ac89395d38

[dsyme]

/repo-assist expand the test matrix for this fix by pushing to this PR and also advise of any possible negative consequences of this change

[github-actions]

✓ Repo Assist completed successfully, see workflow run.

Generated by 🌈 Repo Assist, see workflow run. Learn more.

[github-actions]

🤖 This is an automated response from Repo Assist.

Test matrix expanded — pushed a new commit with 4 additional test cases:

• A fixture matching the exact original issue shape (only conditional PropertyGroups, no unconditional TargetFramework/TargetFrameworks fallback at all).
• Case-insensitive Configuration coverage (dEbUg/rElEaSe) for the conditional-frameworks fixture.
• Assertion that the correct default framework (first one listed for the matched configuration) is picked.
• Assertion that GetOutputDirectory resolves correctly for a specific requested TargetProfile (net45) inside conditional PropertyGroups.

All net9.0 tests pass (47/47, up from 39/39). net461 still can't run in this sandbox (mono not installed — pre-existing environment limitation, not a regression).

Possible negative consequences of this change:

1. Scope is intentionally narrow. Only getOutputDirectory was changed to seed Configuration/Platform when evaluating TargetFramework(s). The unconditioned getTargetFramework/getTargetFrameworksParsed (used by getTargetProfiles, which drives dependency-graph target-profile resolution in InstallProcess.fs, UpdateProcess.fs, PackageMetaData.fs) are untouched. This means a project whose only TargetFramework(s) live in a Configuration-conditioned PropertyGroup will now get correct output paths via paket pack, but paket install/paket restore dependency-graph target-profile detection could still miss such frameworks (falls back to net40), since it doesn't seed Configuration/Platform. This is an existing limitation, not something this PR introduces, but it's worth flagging as a follow-up.
2. Behaviour change is confined to when Configuration/Platform conditions gate the frameworks — projects with unconditioned TargetFramework(s) (the vast majority) see no change, since the seeded values only affect evaluation of conditional PropertyGroups, and Map.add still lets later (deeper/matching) definitions override earlier ones exactly like MSBuild does.
3. Case sensitivity: MSBuild condition comparisons in this codebase already use OrdinalIgnoreCase (see conditionMatches), so Configuration=dEbUg matches =='Debug' correctly — verified by the new tests.
4. No new dependencies, no public API changes; risk is low and localized to getOutputDirectory.

Generated by 🌈 Repo Assist, see workflow run. Learn more.
_{Comment /repo-assist to run again}

_{Add this agentic workflow to your repo}

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@ae8d551f07c7ed7619f8c58c7bb4c3ac89395d38