[Bug] get_project_graph reports TargetFramework "netcoreapp1.0" for net10.0 projects

[m5x]

get_project_graph reports TargetFramework "netcoreapp1.0" for net10.0 projects

Tool: CWM.RoslynNavigator 0.7.2 (cwm-roslyn-navigator, installed as a global dotnet tool)
Environment: .NET SDK 10.0.110, Linux x64; MCP over stdio

Summary

get_project_graph reports "TargetFramework": "netcoreapp1.0" for projects that actually target net10.0. It looks like the TFM string is parsed as a legacy netcoreappX.Y moniker and net10.0 gets collapsed to 1.0.

Repro

1. A solution with SDK-style projects targeting net10.0 — the TargetFramework is inherited from a root Directory.Build.props:

   <TargetFramework>net10.0</TargetFramework>

2. Start cwm-roslyn-navigator in the repo root (solution auto-discovered, .slnx format).

3. Call get_project_graph (no args).

Actual:

{"Solution":"TestbedKit.slnx","Projects":[
  {"Name":"TestbedKit","Path":".../src/TestbedKit/TestbedKit.csproj",
   "TargetFramework":"netcoreapp1.0","References":[]},
  {"Name":"TestbedKit.Tests","Path":".../tests/TestbedKit.Tests/TestbedKit.Tests.csproj",
   "TargetFramework":"netcoreapp1.0","References":["TestbedKit"]}]}

Expected: "TargetFramework": "net10.0" for both projects.

Notes

• Everything else about the workspace loads correctly (symbols, references, diagnostics all resolve fine), so this appears to be display/parse-only.
• Possibly a Version.Parse-style mapping that treats net10.0 as netcoreapp 1.0 — net8.0/net9.0 may misreport similarly (untested here).
• The TFM here comes from Directory.Build.props rather than the .csproj itself, which may or may not be relevant.

[iammukeshm]

Fixed in #20 — the fallback TFM detection picked the longest NET* preprocessor symbol, so the compat symbol NETCOREAPP1_0_OR_GREATER beat NET10_0_OR_GREATER and misreported as netcoreapp1.0. Detection now matches only exact TFM symbols (NET10_0, NETSTANDARD2_0, etc.), covered by regression tests. Ships in CWM.RoslynNavigator 0.7.3.