Eliminate the vendored vs-solutionpersistence fork — upstream nuget or inline within Fallout #248

Why

`Fallout.VisualStudio.SolutionPersistence` is currently a fork of a fork of Microsoft's solution-persistence library:

• Microsoft → `microsoft/vs-solutionpersistence` (upstream)
• matkoch → `matkoch/vs-solutionpersistence` (his fork adding netstandard2.0)
• ChrisonSimtian → `ChrisonSimtian/vs-solutionpersistence` (our fork preserving matkoch's netstandard2.0 patches with attribution)

The sources live under `vendor/vs-solutionpersistence/` as a git submodule tracking our personal-account repo. Our wrapper csproj at `src/Fallout.VisualStudio.SolutionPersistence/` multi-targets netstandard2.0;net8.0;net10.0, compiles the submodule's .cs files (92 source files), and packs as Fallout.VisualStudio.SolutionPersistence with AssemblyName=Microsoft.VisualStudio.SolutionPersistence to preserve type identity for Fallout.SolutionModel consumers.

This is brittle:

• A git submodule pointing at a personal-account repo couples the project's build to one maintainer's GitHub account staying alive and accessible.
• Rebasing the submodule on upstream requires manual coordination across three forks every time Microsoft ships a change we want.
• The netstandard2.0 patch is the load-bearing reason we forked, but upstream's targeting policy may have shifted — worth re-checking.
• Submodules add real cognitive load for new contributors (git submodule update --init --recursive, etc.).

Chris explicitly does not want another side repository to replace this one. Two acceptable paths only:

Acceptable paths

A) Switch back to the upstream nuget package

If Microsoft.VisualStudio.SolutionPersistence on nuget.org now supports the TFMs we need (or we can drop one of our TFMs to match what's supported), simply reference the upstream package and delete Fallout.VisualStudio.SolutionPersistence + the submodule entirely.

• Investigation needed: what TFMs does the current upstream package support?
• What's our actual minimum TFM requirement? The submodule csproj targets netstandard2.0;net8.0;net10.0 — is netstandard2.0 still load-bearing (probably yes for the source generator path) or can we drop it?
• Has upstream changed their stance on netstandard2.0 since matkoch's fork was created?

B) Inline the source files directly into Fallout

If upstream doesn't fit, copy the necessary source files directly into src/Fallout.VisualStudio.SolutionPersistence/ (no submodule, no separate repo). Track upstream by manual sync when needed — git diff against a clean clone of upstream Microsoft, apply patches.

• Smaller surface than the current 92-file submodule? Identify which files we actually need.
• License + attribution preserved via per-file headers and a NOTICE file referencing Microsoft + matkoch.
• Sync cadence is whenever a Microsoft fix matters; otherwise leave it alone.

NOT acceptable

• Replacing the personal-account submodule with another personal- or org-account side repo (e.g. Fallout-build/vs-solutionpersistence). The whole point is to stop maintaining a separate repo.

Action

• Audit current upstream Microsoft.VisualStudio.SolutionPersistence nuget package — TFMs supported, version, breaking changes since the fork point
• Decide path A vs B based on the audit (one PR for each path's spike, or a write-up issue, whichever's faster)
• If A: replace Fallout.VisualStudio.SolutionPersistence csproj with a PackageReference in Directory.Packages.props; update Fallout.SolutionModel's reference; delete vendor/vs-solutionpersistence/ and the submodule entry in .gitmodules; archive ChrisonSimtian/vs-solutionpersistence on GitHub
• If B: copy the load-bearing .cs files into src/Fallout.VisualStudio.SolutionPersistence/; preserve license headers + add NOTICE; delete vendor/vs-solutionpersistence/ and the submodule entry; document the manual-sync recipe in docs/agents/conventions.md or a sibling doc; archive ChrisonSimtian/vs-solutionpersistence
• Either way: ensure Fallout.SolutionModel still builds + tests pass on all three current TFMs

Coordinate with

• chore(ci): drop Qodana #11 / Fallout-build org transfer — once the GitHub org exists, archive-vs-keep on ChrisonSimtian/vs-solutionpersistence is part of the personal-asset cleanup
• The Fallout.SolutionModel consumer — it's the only direct dependent
• AGENTS.md → docs/agents/repository-layout.md (vendored entry) — update once this lands

Done when

• No vendor/ directory, no .gitmodules entry, no submodule for solution-persistence
• No side repository under any account being relied on for this dependency
• Either upstream nuget consumed directly, or sources inlined under src/Fallout.VisualStudio.SolutionPersistence/ with proper license/attribution
• ChrisonSimtian/vs-solutionpersistence archived on GitHub (or transferred if path A and the fork is no longer needed by anyone)